Device context determination

ABSTRACT

Systems and methods are provided for context determination. In one implementation one or more indications can be received, each of the one or more indications corresponding to a perception of one or more access points in relation to a user device. The one or more indications can be processed to determine one or more characteristics of at least one of the one or more access points. Based on the one or more characteristics, a context of the user device can be determined.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/410,082, filed Dec. 21, 2014 (now U.S. Pat. No. 9,986,084) which is aUS National Stage application of International Application No.PCT/IB2013/001582, filed Jun. 21, 2013, which is related to and claimsthe benefit of: U.S. Patent Application No. 61/662,659, filed Jun. 21,2012, U.S. Patent Application No. 61/676,704, filed Jul. 27, 2012, U.S.Patent Application No. 61/694,172, filed Aug. 28, 2012, U.S. PatentApplication No. 61/694,180, filed Aug. 28, 2012, U.S. Patent ApplicationNo. 61/704,113, filed Sep. 21, 2012, U.S. Patent Application No.61/731,394, filed Nov. 29, 2012, U.S. Patent Application No. 61/732,693,filed Dec. 3, 2012, U.S. Patent Application No. 61/793,633, filed Mar.15, 2013, U.S. Patent Application No. 61/815,998, filed Apr. 25, 2013,U.S. Patent Application No. 61/825,034, filed May 19, 2013, U.S. PatentApplication No. 61/825,358, filed May 20, 2013, and U.S. PatentApplication No. 61/829,967, filed May 31, 2013 each of which isincorporated herein by reference in their respective entireties.

TECHNICAL FIELD

This disclosure relates generally to the field of mobile deviceidentification, and, in particular, to computer-implemented systems andmethods for context determination.

BACKGROUND

There are approximately 4.6 billion cellular phone subscriptions in theworld over which it is estimated that more than 2 trillion text (SMS)messages are sent annually. There are also over 800 milliontransportation vehicles in the world. The magnitude of these statisticsindicates that cellular phone use in vehicles is inevitable and islikely to remain quite common, unless preventative measures are taken.

Drivers using a hand-held cellular phone or smartphone for talking, textmessaging, and/or for executing other applications or ‘apps’ whiledriving has become a problem of near-epidemic proportions. Studies ondistracted driving have shown that by talking on a cell phone, a driverincreases his/her risk of an accident by a factor of four. Even worse,sending text messages increases a driver's accident risk 23-fold.Additionally, studies have shown that the temptation to use a cellularphone for texting, talking, and other activities while operating avehicle is not limited to younger drivers—adult drivers have been shownto text more often than younger ones.

In response to this growing concern and danger, numerous regulatoryactions have been put in place to attempt to mitigate such phone-baseddistractions to drivers. For example, in the United States, thirtystates have banned drivers of vehicles from texting, and many havesubsequently increased the penalties for such violations.Driving-while-texting has also been banned throughout Europe and manyother countries around the world. Additionally, talking on a hand-heldcellular phone while driving a vehicle has been banned in eight USstates, and such cell phone use has been banned in all of Europe and inmany other countries.

The effectiveness of these laws alone, without an effective means ofenforcement, is questionable. Being that cellular phones are generallysmall and discreet and drivers are frequently in motion, it is oftendifficult for law enforcement personnel to effectively police for suchviolations. Indeed, statistics show that accidents arising from cellularphone-based distractions are increasing as the popularity of suchdevices increases.

Given the easy accessibility of cell phones to drivers, many drivers'apparent desire to operate their cellular phones while driving, and thedifficulties attendant with enforcing laws prohibiting cellular phoneuse, it is likely that drivers will continue to use cellular phones fortexting, talking, and/or other activities (e.g., playing games orrunning applications), for the foreseeable future.

Moreover, it can be appreciated that the usage of mobile devices invarious locations and/or settings can be detrimental on a number oflevels. For instance, anecdotal evidence suggests that the proliferationof mobile devices such as smartphones has resulted in an increase ofmobile device usage by students during classes/lectures, serving todistract such students from properly absorbing the material beingtaught. Additionally, many students have become adept at using suchdevices discreetly, resulting in many instances of cheating beingfacilitated through the use of mobile devices.

It is with respect to these and other considerations that the disclosuremade herein is presented.

SUMMARY

Technologies are presented herein in support of a system and method forcontext determination. According to one aspect, one or more indicationscan be received, each of the one or more indications corresponding to aperception of one or more access points in relation to a user device.The one or more indications can be processed to determine one or morecharacteristics of at least one of the one or more access points. Basedon the one or more characteristics, a context of the user device can bedetermined.

According to another aspect, one or more operational characteristics ofa device can be identified and one or more contextual determinationmethods can be selectively employed in relation to the device, based onthe operational characteristics.

According to another aspect, one or more power charging aspects can bedetermined in relation to a user device, the one or more power chargingaspects can be processed to determine a context of the user device, andone or more operations can be initiated, based on the context, inrelation to the user device.

These and other aspects, features, and advantages can be appreciatedfrom the accompanying description of certain embodiments and theaccompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level diagram illustrating an exemplary configurationof an in-vehicle determination system;

FIGS. 2A-2C are flow diagrams showing routines that illustrate broadaspects of methods for determining an in-vehicle role of a user and/oran in-vehicle location of a mobile device in accordance with variousexemplary embodiments disclosed herein;

FIG. 3 is a flow diagram showing a routing that illustrates a broadaspect of a method for enabling, disabling and/or modifying at least afeature of a mobile device in accordance with at least one exemplaryembodiment disclosed herein;

FIG. 4 is a flow diagram showing a routine that illustrates a broadaspect of a method for determining an in-vehicle role of a user of amobile device and/or a handheld state of a mobile device and/or avehicle class of a vehicle containing the first mobile device using acentral machine in accordance with at least one exemplary embodimentdisclosed herein;

FIG. 5 is a flow diagram showing a routine that illustrates a broadaspect of a method for determining a vehicle class of a vehicle using amobile device in accordance with at least one exemplary embodimentdisclosed herein;

FIG. 6 is a flow diagram showing a routine that illustrates a broadaspect of a method of determining a handheld state a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 7 is a flow diagram showing a routine that illustrates a broadaspect of a method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 8 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 9A is a diagram depicting an exemplary relative coordinate systemof a mobile device;

FIG. 9B is a diagram depicting exemplary relative accelerations andgyroscopic rotations of a mobile device;

FIG. 9C is a diagram depicting an exemplary gyroscopic sign convention,as used herein;

FIG. 10 is a diagram depicting an exemplary coordinate system used inrelation to a vehicle;

FIGS. 11A-B are diagrams depicting a mobile device and its respectiveexemplary coordinate system in various orientations in relation to a carand its exemplary respective coordinate system;

FIG. 12 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 13 is a flow diagram showing a routine that illustrates a broadaspect of another method of restricting operation of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 14 is a flow diagram showing a routine that illustrates a broadaspect of a method for orienting a coordinate system of a mobile devicein accordance with at least one embodiment disclosed herein;

FIG. 15 is a flow diagram is described showing a routine thatillustrates a broad aspect of a method for selectively restricting anoperation of a mobile device in accordance with at least one embodimentdisclosed herein;

FIG. 15A is an exemplary lock screen, in accordance with at least oneembodiment disclosed herein;

FIG. 15B is an exemplary visual capture that can be processed toidentify a presence of a fastened seatbelt, in accordance with at leastone embodiment disclosed herein;

FIG. 15C depicts the “required orientation” of a mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 15D depicts an exemplary screenshot showing visual feedback thatcan be provided to a user during authentication in accordance with atleast one embodiment disclosed herein;

FIG. 15E depicts an exemplary screenshot showing visual feedback thatcan be provided to a user during authentication in accordance with atleast one embodiment disclosed herein;

FIG. 15F depicts a mobile device, and specifically the locations of theforward-facing and rear-facing cameras of the mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 15G is an illustration depicting a 90 degree angle of incidencebetween the user's eyes/gaze/face/smile etc. and a mobile device, inaccordance with at least one embodiment disclosed herein;

FIGS. 15H-T depict exemplary aspects of an authentication sequence inaccordance with at least one embodiment disclosed herein;

FIG. 16 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively restricting operation of a mobiledevice in accordance with at least one embodiment disclosed herein;

FIG. 17 is a flow diagram showing a routine that illustrates a broadaspect of a method for authenticating an in vehicle role of a user of amobile device and/or modifying a restriction of a mobile device inaccordance with at least one embodiment disclosed herein;

FIG. 17A is a flow diagram showing particular aspects of the validationstep of FIG. 17, in accordance with at least one embodiment disclosedherein;

FIG. 17B is an illustration depicting an orientation of a mobile devicein relation to a typical line of sight of the driver in a moving car, inaccordance with at least one embodiment disclosed herein,

FIG. 18 is a flow diagram is described showing a routine thatillustrates a broad aspect of a method for selectively restricting anoperation of and/or selectively modifying a restriction employed atmobile device, in accordance with at least one embodiment disclosedherein;

FIG. 19 depicts an exemplary determination of orientation of a devicebased on visual capture(s) in accordance with at least one embodimentdisclosed herein;

FIG. 20 depicts the orientation and/or location of mobile device inorder to provide the requisite stability described herein, in accordancewith at least one embodiment disclosed herein;

FIG. 21 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively restricting a mobile device, inaccordance with at least one embodiment disclosed herein;

FIG. 22 is a flow diagram showing a routine that illustrates a broadaspect of a method for eliciting an authentication at a mobile device,in accordance with at least one embodiment disclosed herein;

FIG. 23 is a flow diagram showing a routine that illustrates a broadaspect of a method for eliciting an authentication at a mobile device,in accordance with at least one embodiment disclosed herein;

FIG. 24 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively modifying a restriction employed at amobile device, in accordance with at least one embodiment disclosedherein;

FIG. 25 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively projecting outputs at a mobiledevice, in accordance with at least one embodiment disclosed herein;

FIG. 26 is a flow diagram showing a routine that illustrates a broadaspect of a method for selectively configuring overt operation of amobile device, in accordance with at least one embodiment disclosedherein;

FIG. 27 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 28 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 29 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 30 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 31 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 32 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 33 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 34 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 35 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 36 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 37 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 38 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 39 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 40 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 41 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 42 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 43 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein

FIG. 44 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 45 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 46 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 47 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein;

FIG. 48 is a flow diagram showing a routine that illustrates aspects ofone or more methods, such as those described in relation to one or moreembodiments described herein; and

FIG. 49 depicts an exemplary implementation of one or more aspectsdescribed herein.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

By way of overview and introduction, the present disclosure detailssystems and methods for determining various user roles and actions asthey relate to the operation of a mobile device within a vehicle such asa car. Being that the usage of mobile devices while driving has beenidentified as a significant cause of car accidents, in addition to lawsthat have been enacted preventing certain use of mobile phones whiledriving, various systems and methods are provided herein which serve toidentify the user of a particular mobile device (for instance, withrespect to their role as a driver or passenger in the car), to identifyvarious aspects of the usage of the device itself (for instance that thedevice is executing a text messaging application), and to identifyinstances when a mobile device deviates from its expected or regularoperation.

As will be described in detail herein, many of these identificationsand/or determinations are made possible through various sensors,components, and elements that are integrated within and/or accessible toa mobile device. As is well known to those of ordinary skill in the art,contemporary smartphones incorporate a plethora of sensors, includingaccelerometers, GPS receivers, and gyroscopes. Various inputs and/ornotifications can be received from these sensors, components, andelements, and can further be processed in a number of ways in order toarrive at various conclusions regarding, among others, the user of themobile device (such as whether the user is a driver or passenger in acar) and/or the status of the mobile device itself, and variousprobabilities can be ascribed to the conclusions. The operation of themobile device can further be adjusted based on such conclusions, forexample, disabling or limiting the operation of a mobile device uponreaching a likely conclusion that the device is being operated by a userwho is driving a car.

It will also be appreciated that the systems and methods disclosedherein can be arranged and/or deployed across a number of scenarios. Inone scenario, the systems and methods can be principally employed at amobile device itself, such as in the form of a mobile application or‘app’ executing on the mobile device. In other scenarios, a centralmachine such as a server in communication with a mobile device canemploy the present systems and methods. Such a centralized architecturecan enable efficient processing and use of a larger database of userdetermination characteristics, eliminates power constraints and enablesthird parties, such as law-enforcement agencies and/or insurancecompanies, to easily monitor and/or adjust the operation of variousmobile devices.

Moreover, it can be appreciated that today, over 70% of teenagers in thedeveloped world own mobile devices, and most bring those devices toschool every day. The ability to use these devices clandestinely inclass results in student distraction, cheating on tests, and frequentdisruptions of the learning environment. The inappropriate use of mobiledevices in class has become one of the major problems in westerneducational systems today, affecting many millions of students andteachers in a very direct way.

The systems and methods described herein define a solution that rendersthe surreptitious use of mobile devices in school impossible, directlyimproving student attention and learning, and empowering educators todecide how (if at all) they may be used in classrooms. In doing so, thepresent systems and methods can limit distraction without interferingwith legitimate device use, which until now has been a major barrier tothe adoption of other proposed solutions.

The following detailed description is directed to systems and methodsfor determining an in-vehicle role of a user of a mobile device,selectively restricting a mobile device, and/or configuring variousoperations of a mobile device. The referenced systems and methods arenow described more fully with reference to the accompanying drawings, inwhich one or more illustrated embodiments and/or arrangements of thesystems and methods are shown. The systems and methods are not limitedin any way to the illustrated embodiments and/or arrangements as theillustrated embodiments and/or arrangements described below are merelyexemplary of the systems and methods, which can be embodied in variousforms, as appreciated by one skilled in the art. Therefore, it is to beunderstood that any structural and functional details disclosed hereinare not to be interpreted as limiting the systems and methods, butrather are provided as a representative embodiment and/or arrangementfor teaching one skilled in the art one or more ways to implement thesystems and methods. Accordingly, aspects of the present systems andmethods can take the form of an entirely hardware embodiment, anentirely software embodiment (including firmware, resident software,micro-code, etc.) or an embodiment combining software and hardware. Oneof skill in the art can appreciate that a software process can betransformed into an equivalent hardware structure, and a hardwarestructure can itself be transformed into an equivalent software process.Thus, the selection of a hardware implementation versus a softwareimplementation is one of design choice and left to the implementer.Furthermore, the terms and phrases used herein are not intended to belimiting, but rather are to provide an understandable description of thesystems and methods.

The terms “determining,” “determine,” and “determination” as used hereinare intended to encompass the determination, identification,computation, calculation, and/or selection, with any degree of certaintyor precision, and/or any other such operation, function, or action as itrelates to the determination, identification, and/or selection of a userof a device such as a mobile device, an in-vehicle role of a user of adevice such as a mobile device, a vehicle or vehicle model/type/class, adevice or device model/type/class (e.g., handheld or wired), anoperation and/or operation state of a device, and/or any other suchsimilar or related operation, function, or action.

The terms “identifying event” and “identifying events” as used hereinare intended to encompass one or more occurrences or instances ofevents, stimuli, or phenomena, including explicitly the perceivedcoordinated or correlated occurrence or instance of two or more suchevents, stimuli, and/or phenomena, such as those originating at one ormore devices. It should be understood that the referenced occurrences orinstances of events, stimuli, or phenomena include single/singularevents, stimuli, or phenomena as well as a set or series of multipleevents, stimuli, or phenomena over a period of time. In addition, thereferenced occurrences or instances of events, stimuli, or phenomenashould also be understood to include one or more coordinations orcorrelations of the occurrence or instance of any number of such events,stimuli, and/or phenomena over any period of time.

The terms “user interface” and “user interfaces” as used herein areintended to encompass one or more input devices, software modulesexecuting in conjunction with one or more operating systems and/or inputdevices, or any other such similar or related device, accessory,apparatus, and/or software application or module that enable orfacilitate input and/or interaction with a computing device.

The terms “detect,” “detected,” “detects,” “detecting,” “detection,” and“detections” as used herein are intended to encompass the detection,measurement, and/or receipt, with any degree of certainty or precision,one or more occurrences or instances of events, stimuli, phenomena, orany other such similar or related inputs that are detectable through oneor more devices, implements or apparatuses.

The term “processing” as used herein is intended to encompass comparing,analyzing, weighing, correlating and/or computing one or more dataitems, elements, or structures, individually or in conjunction with oneanother, using a digital processor in conjunction with one or moresoftware modules and/or applications.

The term “communicatively coordinated” as used herein is intended toencompass direct or indirect communication between two or more devices,accessories, and/or apparatuses, expressly including communicationsbetween a first device and a central machine, wherein the centralmachine is in turn in communication at some interval with a seconddevice. In such a scenario, though the first device and the seconddevice are not, necessarily, in direct or indirect communication withone another, it can be said that they are communicatively coordinatedwith one another by virtue of their mutual connection to the referencedcentral machine.

The terms “feature” and “features” as used herein are intended toencompass operations, functions, activities, or any other such similaror related actions, whether automated/automatic or user-initiated, thatoccur at or in conjunction with one or more devices, machines,applications, and/or apparatuses.

The terms “notification” and “notifications” as used herein are intendedto encompass one or more messages, transmissions, and/or data packets,such as electronic messages, which contain one or more data elements(such as inputs) related or relevant to one or more of the steps,operations, and/or processes disclosed herein. An illustration of onesuch notification can be one or more electronic messages which containinformation or data reflecting a first input from an accelerometer, agyroscope, and/or a GPS receiver at a mobile device. Such inputs can begrouped together into one or more notifications, and these notificationscan in turn be transmitted to and/or received by other devices (such asa central machine) where they can be further processed.

The terms “vehicle class” and “vehicle classes” as used herein areintended to encompass one or more types, categories, and/or models ofvehicle. By way of example, airplanes, trains, automobiles, motorcycles,and boats can all be said to be different vehicle classes. By way offurther example, sub-categories within a given vehicle class can also beunderstood to be different vehicle classes. Thus, the automobile vehicleclass can be further sub-divided into further vehicle classes such assedans, vans, sport utility vehicles (SUVs), and convertibles. Thesesub-categories can also be said to be vehicle classes within the meaningof the term as used herein.

The terms “operation state” and “operation states” as used herein areintended to encompass the states of a device, including any and alloperations, functions, capacities, and/or capabilities, including,explicitly, a set and/or series of any number of operations, functions,capacities, and/or capabilities, that can be achieved by and/or inconjunction with a device, such as a mobile device. Examples of anoperation state include, but are not limited to: an execution of anapplication (such as an internet browser application) at a mobiledevice, a transmission of a notification (such as sending a text messageor email message), a capacity to receive text messages, and a capabilityto type text using a keyboard. Accordingly, the various transformations,adjustments, and/or modifications disclosed herein that relate to anoperation state and/or operation states should be understood to refer tosuch transformations, adjustments, and/or modifications that pertain topractically any and all operations, functions, capacities, and/orcapabilities that can be achieved by and/or in conjunction with adevice, such as a mobile device.

The terms “handheld state” and “handheld states” as used herein areintended to encompass one or more states of a mobile device with respectto whether or not a user is in direct or indirect physical contact withthe device. For example, the handheld state of a device in instanceswhere a user holds the device in his/her hand, carries the device inhis/her pocket, and/or balances the device on his/her knee can all besaid to be “handheld.” By way of further example, the handheld state ofa device in instances where the device is positioned in a dock orcradle, and/or is otherwise not in direct or indirect contact with auser can be said to be “non-handheld.”

The terms “operational capacity” and “operational capacities” as usedherein are intended to encompass one or more operation states of amobile device, particularly with respect to a central machine such as aserver. By way of example, an operational capacity of a mobile devicecan be a voice or data connection that is provided to a mobile devicethrough a central machine, such as that of a voice/data serviceprovider. Accordingly, it can be appreciated that a transformation,modification, and/or adjustment of such an operational capacitypreferably entails such a transformation, modification, and/oradjustment that is initiated and/or effected by a central machine,preferably in relation to a mobile device. For example, a centralmachine can transmit an instruction and/or notification to a mobiledevice, such instruction/notification directing the transformation,modification, and/or adjustment be implemented at the mobile device. Byway of further example, a central machine can implement atransformation, modification, and/or adjustment at the central machineitself, wherein such a transformation, modification, and/oradjustment—such as the stopping of voice and/or data connections to amobile device—ultimately effect the functionality of the device itself.In both such cases it can be said that the central machine hastransformed, modified, and/or adjusted the operational capacity of themobile device.

The terms “user” and “users” as used herein are intended to encompassone or more individuals, persons, and/or entities whose presence adevice or machine can preferably be directly or indirectly aware. Itshould be understood that while in certain scenarios a user can interactwith a device, in other scenarios a particular individual, person,and/or entity can be said to be a “user” within the context of thepresent disclosure, despite not interacting with a particular device.

The terms “tactile sensor” and “tactile sensor(s)” as used herein areintended to encompass one or more buttons, touchscreens, and/orcomponents that enable a user to interact with a device in a tactilefashion. Examples of such tactile sensors include, but are not limitedto, buttons (such as those that comprise a keyboard), switches, as wellas touch screen displays (such as capacitive and resistive displays)which both display information and allow the tactile interaction withsuch information. It should be further understood that such tactilesensors are preferably further capable of perceiving a plurality ofsimultaneous tactile interactions. Examples of such functionalityinclude mutlitouch technologies, as are known to those of ordinary skillin the art.

The terms “visual capture” and “visual captures” as used herein areintended to encompass one or more operations, functions, and/or actionsthat relate to the optical perception and/or documentation of one ormore visual items, elements, and/or phenomena. Examples of such visualcaptures include, but are not limited to, photographs, images, videos,and/or any other such method of visual perception and/or documentation.Accordingly, it can be appreciated that certain visual capturescorrespond to a single instance (such as a photograph) while othervisual captures correspond to multiple instances (such as a series ofphotographs and/or a video).

The term “in-vehicle role indicator” as used herein is intended toencompass one or more items, elements, and/or indicators that relate toone or more aspects associated with and/or corresponding to thein-vehicle role of a user in a vehicle (e.g., whether a user is or isnot a driver, is or is not a passenger, etc.). For example, one suchin-vehicle role indicator is identifying in a picture of two hands of adriver grasping the steering wheel of a vehicle. Using one or moreoptical recognition methods, such as those known to one of ordinaryskill in the art, one or more images and/or videos can be processed inorder to identify the presence of two hands grasping a steering wheel,thus indicating that a particular vehicle is being operated by a driverusing two hands and therefore it can be reasonable concluded that theuser who took such an image is not the driver. By way of furtherexample, another such in-vehicle role indicator can be capturing apicture that can be processed to identify that a seatbelt extends fromthe right shoulder to left thigh of the wearer. Such an identificationalso reasonably suggests that the wearer is not a driver (as theseatbelt of a driver traditionally extends from the left shoulder to theright thigh).

It should be further understood that while the various computing devicesand machines referenced herein, including but not limited to the firstmobile device, the second mobile device, the central machine, or anyother such similar or related devices or machines are referred to hereinin a as individual/single devices and/or machines, in certainarrangements the referenced devices and machines, and their associatedand/or accompanying operations, features, and/or functionalities can bearranged or otherwise employed across any number of devices and/ormachines, such as over a network connection, as is known to those ofskill in the art.

In addition, it should be understood that while the term “input” is usedherein in the singular form, this is merely for the sake of clarity andconvention. However, the referenced terms should be understood toencompass both singular inputs as well as a plurality (two or more)inputs, such as a set of inputs.

It should be understood that the terms “lateral acceleration,”“x-acceleration,” and “x-axis acceleration” as used herein are usedinterchangeably, and should thus be understood to possess the samemeaning and connotation. Additionally, the terms “forward acceleration,”“y-acceleration,” and “y-axis acceleration” as used herein are usedinterchangeably and should thus be understood to possess the samemeaning and connotation. In addition, the terms “upward acceleration,”“z-axis acceleration,” “z-acceleration” as used herein are usedinterchangeably and should thus be understood to possess the samemeaning and connotation.

It should also be understood that the terms “yaw,” “gyroscopic yaw,”“angular velocity around the z-axis,” and “rotation around the z-axis”as used herein are used interchangeably, and should thus be understoodto possess the same meaning and connotation. In addition, the terms“roll,” “gyroscopic roll,” “angular velocity around the y-axis,” and“rotation around the y-axis,” as used herein are used interchangeably,and should thus be understood to possess the same meaning andconnotation. Additionally, the terms “pitch,” “gyroscopic pitch,”“angular velocity around the x-axis,” and “rotation around the x-axis”as used herein are used interchangeably, and should thus be understoodto possess the same meaning and connotation.

An exemplary computer system is shown as a block diagram in FIG. 1 whichis a high-level diagram illustrating an exemplary configuration of adetermination system 100. In one arrangement, mobile device 105 can be aportable computing device such as a mobile phone, smartphone, or PDA. Inother arrangements, mobile device 105 can be a tablet computer, a laptopcomputer, a personal computer, or an in-vehicle computer (e.g., ECU/OBD)though it should be understood that mobile device 105 of determinationsystem 100 can be practically any computing device capable of embodyingthe systems and/or methods described herein.

Mobile device 105 of determination system 100 includes a control circuit140 which is operatively connected to various hardware and softwarecomponents that serve to enable operation of the determination system100. The control circuit 140 is operatively connected to a processor 110and a memory 120. Processor 110 serves to execute instructions forsoftware that can be loaded into memory 120. Processor 110 can be anumber of processors, a multi-processor core, or some other type ofprocessor, depending on the particular implementation. Further,processor 110 can be implemented using a number of heterogeneousprocessor systems in which a main processor is present with secondaryprocessors on a single chip. As another illustrative example, processor110 can be a symmetric multi-processor system containing multipleprocessors of the same type.

Preferably, memory 120 and/or storage 190 are accessible by processor110, thereby enabling processor 110 to receive and execute instructionsstored on memory 120 and/or on storage 190. Memory 120 can be, forexample, a random access memory (RAM) or any other suitable volatile ornon-volatile computer readable storage medium. In addition, memory 120can be fixed or removable. Storage 190 can take various forms, dependingon the particular implementation. For example, storage 190 can containone or more components or devices. For example, storage 190 can be ahard drive, a flash memory, a rewritable optical disk, a rewritablemagnetic tape, or some combination of the above. Storage 190 also can befixed or removable.

One or more software modules 130 are encoded in storage 190 and/or inmemory 120. The software modules 130 can comprise one or more softwareprograms or applications having computer program code or a set ofinstructions executed in processor 110. Such computer program code orinstructions for carrying out operations for aspects of the systems andmethods disclosed herein can be written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Java, Smalltalk, C++ or the like and conventionalprocedural programming languages, such as the “C” programming languageor similar programming languages. The program code can execute entirelyon the mobile device 105, partly on mobile device 105, as a stand-alonesoftware package, partly on mobile device 105 and partly on a remotecomputer/device or entirely on the remote computer/device or server. Inthe latter scenario, the remote computer can be connected to mobiledevice 105 through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection can be made to anexternal computer (for example, through the Internet using an InternetService Provider).

Software modules 130, including program code/instructions, are locatedin a functional form on one or more computer readable storage devices(such as memory 120 and/or storage 190) that can be selectivelyremovable. The software modules 130 can be loaded onto or transferred tomobile 105 for execution by processor 110. It can also be said that theprogram code of software modules 130 and one or more computer readablestorage devices (such as memory 120 and/or storage 190) form a computerprogram product.

It should be understood that in some illustrative embodiments, one ormore of software modules 130 can be downloaded over a network to storage190 from another device or system via communication interface 150 foruse within determination system 100. For instance, program code storedin a computer readable storage device in a server can be downloaded overa network from the server to determination system 100.

Preferably, included among the software modules 130 is a determinationmodule 170 that is executed by processor 110. During execution of thesoftware modules 130, and specifically the determination module 170, theprocessor 110 configures the control circuit 140 to determine anin-vehicle role of a user of the mobile device 105, as will be describedin greater detail below. It should be understood that while softwaremodules 130 and/or determination module 170 can be embodied in anynumber of computer executable formats, preferably software modules 130and/or determination module 170 comprise one or more applications or‘apps’ that are configured to be executed at mobile device 105 and/or inrelation to mobile device 105. In other arrangements, software modules130 and/or determination module 170 are incorporated and/or integratedwithin operating system 176. Furthermore, in certain arrangements,software modules 130 and/or determination module 170 can be configuredto execute at the request or selection of a user of mobile device 105(or any other such user having the ability to execute a program inrelation to mobile device 105, such as a network administrator), whilein other arrangements mobile device 105 can be configured toautomatically execute software modules 130 and/or determination module170, without requiring an affirmative request to execute. The advantagesof such an automatic arrangement can be appreciated in context of aregulatory scheme that mandates or recommends that software modules 130and/or determination module 170 be executed by a mobile device 105 someor all of the time, in furtherance of a campaign to improve driversafety. It should also be noted that while FIG. 1 depicts memory 120oriented on control circuit 140, in an alternate arrangement, memory 120can be operatively connected to the control circuit 140. In addition, itshould be noted that other software modules (such as user interface 172and operating system 176) and other information and/or data relevant tothe operation of the present systems and methods (such as database 174)can also be stored on storage 190, as will be discussed in greaterdetail below.

A communication interface 150 is also operatively connected to controlcircuit 140. Communication interface 150 can be any interface thatenables communication between the mobile device 105 and externaldevices, machines and/or elements. Preferably, communication interface150 includes, but is not limited to, a modem, a Network Interface Card(NIC), an integrated network interface, a radio frequencytransmitter/receiver (e.g., Bluetooth, cellular, NFC), a satellitecommunication transmitter/receiver, an infrared port, a USB connection,or any other such interfaces for connecting mobile device 105 to othercomputing devices and/or communication networks such as the Internet.Such connections can include a wired connection or a wireless connection(e.g. 802.11) though it should be understood that communicationinterface 150 can be practically any interface that enablescommunication to/from the control circuit 140.

At various points during the operation of determination system 100,mobile device 105 can communicate with one or more mobile devices 160A-N(collectively mobile devices 160). The mobile devices 160 transmitand/or receive data to/from the mobile device 105, thereby preferablyenhancing the operation of the determination system 100, as will bedescribed in greater detail below. It should be understood that mobiledevices 160 can be in direct communication with mobile device 105,indirect communication with mobile device 105, and/or can becommunicatively coordinated with mobile device 105, as will be describedin greater detail below. While mobile device 160 can be practically anydevice capable of communication with mobile machine 105, in thepreferred embodiment mobile device 160 is a handheld/portable computer,smartphone, personal digital assistant (PDA), tablet computer, and/orany portable device that is capable of transmitting and receiving datato/from mobile device 105. It should also be appreciated that in manyarrangements, mobile device 160 will be substantially identical, from astructural and functional perspective, to mobile device 105.

It should be noted that while the FIG. 1 depicts the determinationsystem 100 with respect to mobile device 160A and mobile device 160N, itshould be understood that any number of mobile devices 160 can interactwith determination system 100 in the manner described herein.

Also preferably connected to and/or in communication with controlcircuit 140 are one or more sensors 145A-145N (generically sensors 145).Generally, sensors 145 are various components, devices, and/or receiversthat are preferably incorporated within and/or in communication withmobile device 105. Sensors 145 preferably detect one or more stimuli,phenomena, or any other such inputs, as will be described in greaterdetail below. Examples of such sensors 145 include, but are not limitedto, an accelerometer 145A, a gyroscope 145B, a GPS receiver 145C, amicrophone 145D, a magnetometer 145E, a camera 145F, a light sensor145G, a temperature sensor 145H, an altitude sensor 145I, a pressuresensor 145J, a proximity sensor 145K, a near-field communication (NFC)device 145L, a compass 145M, and a tactile sensor 145N. As will bedescribed in greater detail below, mobile device 105 can preferablyreceive one or more inputs from one or more sensors 145 in order todetermine an in-vehicle role of a user of mobile device 105 and/or toselectively restrict the operation of the mobile device.

In certain arrangements, one or more external databases and/or servers162 are also in communication with mobile device 105. As will bedescribed in greater detail below, database/server 162 is preferably acomputing and/or storage device, and/or a plurality of computing and/orstorage devices, that contain(s) information, such as determinationcharacteristics, that can be relevant to the determination of anin-vehicle role of a user of mobile device 105.

Additionally, in certain arrangements a vehicle data system 164, such asan on board diagnostic (OBD) computer or computing device (e.g., OBD-I,OBD-II), an engine control unit (ECU), a roll system, an airbag system,a seat-weight sensor system, a seat-belt sensor system, and/or ananti-lock braking system (ABS) can also be in communication with mobiledevice 105. Vehicle data system 164 preferably provides data and/orinformation from the vehicle itself that can also be relevant to variousdeterminations disclosed herein, such as the determination of anin-vehicle role of a user of mobile device 105, as will be described ingreater detail below.

At this juncture it should be noted that in certain arrangements, suchas the one depicted in FIG. 1, mobile devices 160, database/server 162,and/or vehicle data system 164 can be in periodic or ongoingcommunication with mobile device 105 thorough a computer network such asthe Internet 166. Although not depicted in FIG. 1, it should beunderstood that in certain other arrangements, mobile devices 160,database/server 162, and/or vehicle data system 164 can be in periodicor ongoing direct communication with mobile device 105, such as throughcommunications interface 150, thus not requiring the presence of anetwork (such as the Internet 166) in order to initiate and maintaincommunications.

In the description that follows, certain embodiments and/or arrangementsare described with reference to acts and symbolic representations ofoperations that are performed by one or more devices, such as thedetermination system 100 of FIG. 1. As such, it will be understood thatsuch acts and operations, which are at times referred to as beingcomputer-executed, include the manipulation by the processor of thecomputer of electrical signals representing data in a structured form.This manipulation transforms the data and/or maintains them at locationsin the memory system of the computer, which reconfigures and/orotherwise alters the operation of the computer in a manner understood bythose skilled in the art. The data structures in which data ismaintained are physical locations of the memory that have particularproperties defined by the format of the data. However, while anembodiment is being described in the foregoing context, it is not meantto provide architectural limitations to the manner in which differentembodiments can be implemented. The different illustrative embodimentscan be implemented in a system including components in addition to or inplace of those illustrated for the determination system 100. Othercomponents shown in FIG. 1 can be varied from the illustrative examplesshown. The different embodiments can be implemented using any hardwaredevice or system capable of running program code. In anotherillustrative example, determination system 100 can take the form of ahardware unit that has circuits that are manufactured or configured fora particular use. This type of hardware can perform operations withoutneeding program code to be loaded into a memory from a computer readablestorage device to be configured to perform the operations.

For example, mobile device 105 can take the form of a circuit system, anapplication specific integrated circuit (ASIC), a programmable logicdevice, or some other suitable type of hardware configured to perform anumber of operations. With a programmable logic device, the device isconfigured to perform any number of operations. The device can bereconfigured at a later time or can be permanently configured to performany number of operations. Examples of programmable logic devicesinclude, for example, a programmable logic array, programmable arraylogic, a field programmable logic array, a field programmable gatearray, and other suitable hardware devices. With this type ofimplementation, software modules 130 can be omitted because theprocesses for the different embodiments are implemented in a hardwareunit.

In still another illustrative example, determination system 100 and/ormobile device 105 can be implemented using a combination of processorsfound in computers and hardware units. Processor 110 can have a numberof hardware units and a number of processors that are configured toexecute software modules 130. In this example, some of the processorscan be implemented in the number of hardware units, while otherprocessors can be implemented in the number of processors.

In another example, a bus system can be implemented and can be comprisedof one or more buses, such as a system bus or an input/output bus. Ofcourse, the bus system may be implemented using any suitable type ofarchitecture that provides for a transfer of data between differentcomponents or devices attached to the bus system. Additionally,communications interface 150 can include one or more devices used totransmit and receive data, such as a modem or a network adapter.

Embodiments and/or arrangements can be described in a general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc., that performparticular tasks or implement particular abstract data types.

The operation of the determination system 100 and the various elementsand components described above will be further appreciated withreference to the method for determining an in-vehicle role of a user ofa mobile device as described below, in conjunction with FIGS. 2A-2C.

Turning now to FIG. 2A, a flow diagram is described showing a routine201 that illustrates a broad aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. It should be appreciated thatseveral of the logical operations described herein are implemented (1)as a sequence of computer implemented acts or program modules running ondetermination system 100 and/or (2) as interconnected machine logiccircuits or circuit modules within the determination system 100. Theimplementation is a matter of choice dependent on the requirements ofthe device (e.g., size, energy, consumption, performance, etc.).Accordingly, the logical operations described herein are referred tovariously as operations, structural devices, acts, or modules. Variousof these operations, structural devices, acts and modules can beimplemented in software, in firmware, in special purpose digital logic,and any combination thereof. It should also be appreciated that more orfewer operations can be performed than shown in the figures anddescribed herein. These operations can also be performed in a differentorder than those described herein.

The process begins at step 210 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input, such as from one or more of sensors 145,software modules 130, user interface 172, operating system 176, and/orcommunication interface 150. Preferably, the first input originates fromone or more identifying events that are perceptible to at least one ofsensors 145, user interface 172, operating system 176, and/orcommunication interface 150. Examples of such an input include, but arenot limited to, an acceleration input that originates from anacceleration event (e.g., the speeding up or slowing down of a car) thatis perceived by accelerometer 145A, a change in geographic locationinput that originates from a location changing event (e.g., the movementfrom one place to another) that is perceived by GPS receiver 145C,and/or one or more instances or user interaction (e.g., typing) that aredetected by user interface 172.

Then, at step 220, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input, such as to identify one or more determinationcharacteristics within the first input, including but not limited touser determination characteristics. As will be described in greaterdetail below, user determination characteristics are one or more aspectsoriginating at and/or derived from an input that provide insightregarding the in-vehicle role and/or identity of the user that isexerting control over and/or otherwise associated with a mobile device,such as mobile device 105. For example, where the first input (receivedat step 210) is the typing of one or more letters into user interface172 (such as to compose a SMS message), determination module 170 cananalyze the typing to identify one or more user determinationcharacteristics (that is, characteristics that contribute to adetermination of the identity of the particular user that is associatedwith mobile device 105, as will be described below). In this case,determination module 170 can analyze the typing patterns within thefirst input (such as the time interval in between the typing ofindividual letters in the SMS message, the average time interval inbetween the typing of individual letters in the SMS message, and/or thevariability among one or more time intervals between the typing ofindividual letters in the SMS message). If there are substantial timeintervals in between the typing of various letters, and/or if the timeintervals in between typed letters vary widely, these factors canindicate that the user of mobile device 105 is likely distracted andthus unable to type consistently. Additional examples of analyzing aninput to identify one or more determination characteristics are providedbelow in EXAMPLE 1.

Upon identifying one or more determination characteristics, such as userdetermination characteristics, based on the analysis of an input, atstep 230 the processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factors (that is, factors that reflect and/or suggestone or more determinations that can be arrived at with respect to one ormore of the mobile device, its location, the user, and/or the vehicle).By way of example, a probability can be computed, based on the userdetermination characteristics, that the in-vehicle role of the user ofmobile device 105 is a driver and/or that the in-vehicle role of theuser of the mobile device 105 is a passenger. That is, in certainarrangements the user determination characteristics identified at step220 can provide varying degrees of certitude as to the identity or roleof a user. So, continuing the example provided with regard to step 220,while, on the one hand, significant time intervals between typed letterscan indicate that the in-vehicle role of the user is a driver, on theother hand if the time intervals in between the various letters are, onaverage, consistent and/or substantially similar this can indicate thatthe user is not necessarily distracted (due to being a driver), butrather is a passenger and is simply not adept at typing. Accordingly, insuch a case, in one arrangement the computed probability for such userdetermination characteristic(s) is preferably a lesser degree ofcertainty that the user is a driver (and/or a passenger), accounting forthe potentially conflicting indications from the various userdetermination characteristics. By way of further example, when the userdetermination characteristics indicate that a lesser degree of typinginconsistency and/or shorter intra-character time intervals exists,processor 110 executing software modules 130 preferably computes aprobability that the in-vehicle role of the user of mobile device 105 isa passenger. Similarly, when a greater degree of typing inconsistencyand/or longer intra-character time intervals exists, processor 110executing software modules 130 preferably computes a probability thatthe in-vehicle role of the user of mobile device 105 is a driver (beingthat the user determination characteristics appear consistent with theactivity of a driver within a vehicle). It should be appreciated thatbecause ranges exist for a particular user determination characteristic(such as typing consistency), a probability of an in-vehicle role ispreferably computed, reflecting a degree of certainty that the user ofmobile device is a driver and/or that the user of mobile device is apassenger.

Then, at step 240, the processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, transformsan operation state of the mobile device 105 based on the determinationfactors (such as the probability computed at step 230), and/or outputsat least one operation state based on the at least one determinationfactor, and/or outputs at least one in-vehicle role of the user based onat least one determination factor, and/or outputs at least onein-vehicle location of the mobile device 105 based on at least onedetermination factor, and/or outputs at least one result based on the atleast one determination factor. Various of these operations will bedescribed in greater detail herein. For example, if the computedprobability indicates that the in-vehicle role of a user of mobiledevice 105 is likely to be a driver, processor 110 can coordinate thedisabling of one or more features of the mobile device 105, such as thedisabling of any and/or all features that enable the entry of text intomobile device 105. In doing so, existing safety risks can be reduced bypreventing a user who has been determined to be likely to be a driver ofa vehicle from using various regular functions of mobile device 105 thatare likely to distract the user and increase safety risks while drivingand/or are restricted and/or prohibited based on the vehicle's current(or most recently known) location, as preferably determined inconjunction with GPS 145C. In other arrangements, one or more othertransformations to the operation state of mobile device can be similarlyapplied based on the computed probability. For example, notifications(such as warning notifications) can be provided at the mobile device105, notifications can be transmitted to third parties (notifying athird party, such as a law enforcement agency, of the in-vehicle role ofthe user of mobile device 105 and/or of the particular operation of themobile device 105, such as that typing is being performed upon mobiledevice 105), instructions can be provided to third parties (such as acellular service provider) to change an operation state of mobile device105 (such as temporarily disabling the communication ability of mobiledevice 105), and/or one or more applications executing or executable onmobile device 105 can be disabled (such as a text messagingapplication).

At this juncture, it can be appreciated that the operationscorresponding to transforming step 240 can be customized and/orconfigured in relation to various probabilities computed at step 230.That is, certain transformations of the operation state of mobile device105 (for example, notifying law enforcement authorities) may only beappropriate when there is a high probability (such as greater than 90%)that the in-vehicle role of a user of mobile device 105 is a driver (andfurther that the driver is interacting with mobile device 105 in anillegal manner while driving), while other transformations may beappropriate even for lower degrees of probability (for example, it maybe appropriate to provide a warning notification at mobile device 105even for a 60% probability that the user is a driver). Yet othertransformations can be employed preemptively, wherein the transformationis applied even before a prohibited interaction (e.g., typing into anSMS program) occurs, thereby avoiding restricted or prohibitedinteraction with mobile device 105, even at the first instance.Furthermore, as referenced above, in certain arrangements the user canconfigure how (that is, the type of transformation) and when (that is,the probability threshold that must be met in order to trigger thetransformation) the operation of mobile device 105 is to be transformed.In other arrangements, a third party can establish such configurations.For example, a regulatory agency can dictate that one or moretransformations be employed on some or all mobile devices when aparticular probability threshold that a user of the device is a driveris met. By way of further example, a car insurance provider can provideincentives to its customers who utilize one or more transformationsand/or probability thresholds suggested and/or dictated by the insurancecompany.

Turning now to FIG. 2B, a flow diagram is described showing a routine202 that illustrates a further aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. Though already noted above, itshould be particularly appreciated with reference to FIG. 2B that moreor fewer operations can be performed than shown in the figures anddescribed herein, and that these operations can be performed in adifferent order than those described herein. Thus, in certainarrangements certain of the operations of FIG. 2B can be performed whileothers are not, and further that in certain arrangements can beperformed in a sequence other than that depicted in FIG. 2B.

The process begins at step 210 where a first input of a first device 105is received, and proceeds to step 220 where the first input is analyzed.Steps 210 and 220 have already been described above with reference toFIG. 2A and thus will not be further elaborated upon here as theiroperation is substantially identical to steps 210 and 220 describedabove.

Then, at step 221, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, receives asecond input from one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150.As described above with reference to step 210, examples of such an inputinclude, but are not limited to, an input corresponding to anacceleration perceived by accelerometer 145A, and/or an inputcorresponding to a change in geographic location as perceived by GPSreceiver 145C.

At step 222, the second input is analyzed by processor 110 executingdetermination module 170, in a manner substantially similar to thatdescribed above with reference to step 220, in order to identify one ormore determination characteristics such as user determinationcharacteristics within the second input. For example, where the secondinput (received at step 221) comprises one or more accelerationsdetected by accelerometer 145A, determination module 170 can analyze theaccelerations to identify one or more user determination characteristicswithin the second input. Here, determination module 170 can analyzevarious patterns within the second input (such as the time and durationof acceleration and deceleration). Certain patterns, such as frequentperiods of sustained forward acceleration interspersed with periodicintervals of rapid and/or brief forward deceleration can indicate thatthe user of mobile device 105 is likely traveling in, if not operating,a car which often follows such an acceleration/deceleration pattern. Asdescribed in detail herein, by identifying one or more userdetermination characteristics (such as identifying that the user ofmobile device 105 is likely traveling in a car, as described above), thecontext and significance of one or more other user determinationcharacteristics can be better evaluated and/or quantified. For example,the typing patterns of a user determined to be traveling in a moving carare, on average, of greater significance in determining whether the userof the device is a driver/passenger. On the other hand, the typingpatterns of a user of a mobile device 105 that has been determined notto be traveling in a moving car can be understood to be, on average, oflesser significance in determining whether the user of the device is adriver/passenger.

Then, at step 223, the processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, cancompare the determination characteristics such as user determinationcharacteristics identified within the first input (such as thoseidentified at step 220) with the determination characteristics such asuser determination characteristics identified within the second input(such as those identified at step 222). In doing so, one or morepatterns, correlations and/or relationships can be identified betweenthe user determinations characteristics of the first input and the userdetermination characteristics of the second input. By way ofillustration, referring to the examples discussed above, the typingpatterns identified at step 220 can be compared with theacceleration/deceleration patterns identified at step 222. In doing so,patterns, correlations, and/or relationships between the typing patternsand acceleration/deceleration patterns can be identified. For example,if time intervals between typed characters and/or typing inconsistenciesincrease at the same time as substantial and/or sudden forward and/orlateral acceleration and/or deceleration, this can further indicate thatthe user of a mobile device 105 is a driver. Being that for a driver toengage in a maneuver with sudden acceleration and/or deceleration thedriver is expected to have temporarily stopped typing due to theincreased attention a driver must pay to his driving activities, if suchaccelerations correlate closely with inconsistent typing speeds and/orslower typing speed and/or such accelerations are just prior to typingdelays, this can be a strong indication that the user of mobile device105 is a driver.

Additional illustrations of scenarios and/or arrangements whereinmultiple inputs are analyzed, compared, correlated, and/or processed inorder to determine various aspects of the roles of one or more users ofa mobile device 105, are provided throughout the present disclosure.

At step 224, the processor 110 executing one or more of software modules130, including, preferably, determination module 170, comparesdetermination characteristics such as user determination characteristics(including, but not limited to, the user determination characteristicsfrom the first input, as identified at step 220, and/or the userdetermination characteristics from the second input, as identified atstep 222) with stored determination characteristics such as userdetermination characteristics, such as those stored at one or moredatabases, such as database 174 (that is local to mobile device 105)and/or database/server 162 (that is external to mobile device 105).Stored user determination characteristics can be archived userdetermination characteristics that have been retained from previous userdeterminations that have been performed, can be generated based onstatistical analyses of previous user determinations, and/or can bedefined or established independent of any particular previous userdetermination. In comparing user determination characteristics (such asthose identified at step 220 and/or step 222) with stored userdetermination characteristics (such as stored user determinationcharacteristics that have historically demonstrated a high degree ofprediction accuracy in determining an in-vehicle role of a user), theprocessor 110 can more accurately compute the probability that thein-vehicle role of the user of mobile device 105 is a driver or that thein-vehicle role of the user of mobile device 105 is a passenger. Forinstance, following the example referenced above with regard to typinginconsistencies, if certain typing patterns have historically beendemonstrated as very reliable in determining the in-vehicle role, of theuser, various identified user determination characteristics (such asthose identified at step 220 and/or step 222) can be compared to suchstored determination characteristics (e.g., highly predictive typingpatterns). If the identified determination characteristics closelycorrelate to highly reliable/predictive stored determinationcharacteristics, the identified determination characteristics can besimilarly considered highly reliable and this correlation can furtherenhance the reliability of the computation of a probability regardingthe in-vehicle role of a particular user. Additional examples andillustrations of such comparisons are provided below at EXAMPLE 1.

At step 225, processor 110 executing one or more of software modules130, including, preferably, determination module 170, receives an inputfrom another device, such as one of mobile devices 160. It should beunderstood that the input received from mobile device 160 is preferablyfrom among the various types of inputs referenced above at steps 210 and221 (for example, an acceleration input that originates from anacceleration event that is perceived by accelerometer 145A, and/or achange in geographic location input that originates from a locationchanging event that is perceived by GPS receiver 145C), and thus willnot be described at length here. However, it should be appreciated thatthis input originates at mobile device 160 (that is, a device externalto mobile device 105), and thus the input from mobile device 160 ispreferably received by mobile device 105 through communication interface150.

Then, at step 226, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesan input of mobile device 105 against an input of one or more mobiledevices 160. In doing so, one or more determination characteristics suchas user determination characteristics can be identified within the inputof the first mobile device 105. By way of example, various typingpatterns and/or tendencies (referenced above) of mobile device 160 canbe processed against similar typing patterns/tendencies of mobile device105 (or, alternatively, various typing patterns and/or tendencies ofmobile device 105 can be processed against similar typingpatterns/tendencies of mobile device 160). In doing so, processor 110can analyze and/or identify the degree to which the input from mobiledevice 105 deviates from the input received from mobile device(s) 160,in a manner similar to the comparison discussed above at step 224(except that here the input of mobile device 105 is being processedagainst an input received from another mobile device 160, as opposed tocomparing one user determination characteristic with storedcharacteristics). Thus, continuing with the provided example, in a casewhere the typing tendencies of mobile device 105 are relativelyinconsistent, if, when processing the typing tendencies received frommobile device(s) 160 against those of mobile device 105 it is revealedthat the typing across many or all of the devices 105 and 160 issimilarly inconsistent, this can indicate that it there is notnecessarily a high probability that the user of mobile device 105 is adriver, despite the inconsistent typing inputs received at the device105 (rather, such inconsistent typing may be the result of the variousdevices 105 and 160 traveling along an off-road or bumpy road, whichwould make consistent typing difficult, even for passengers in avehicle). Additionally, if the typing tendencies of mobile device 105are relatively consistent, however when processing such input(s) againstinputs from mobile device(s) 160 it is revealed that the typingtendencies of the user of mobile device 105 are actually relativelyinconsistent, this can indicate a higher probability that the user ofmobile device 105 is a driver of a vehicle (even though the input frommobile device 105, in-and-of-itself, may not have generated the sameconclusion).

It should be noted that various limitations and/or filters can beimposed upon the receiving at step 225 and/or the processing at step226, to ensure the most accurate results possible. That is, while incertain arrangements it can be beneficial to receive inputs frompractically any mobile device 160 that is capable of communication withmobile device 105, in other arrangements it can be preferably to limitthe number of devices and/or inputs that are received by mobile device105 on the basis of one or more factors to ensure that the inputs beingreceived by mobile device 105 from such external devices 160 are thosethat can be expected to be of greatest relevance. Examples of factorsthat can be considered in imposing such limitations and/or filtersinclude proximity to mobile device 105 and/or similarity/compatibilitywith mobile device 105. To illustrate, in processing the typingtendencies of device 105 against those of another device 160, it can bepreferable to ensure that device 160 is in close proximity to mobiledevice 105 (such as through a comparison of the location coordinatesobtained from their respective GPS receivers or by causing one or moreof the mobile devices to emit one or more tones and/or signals (e.g., anaudio tone) that can then be received on other mobile devices that arein close proximity, as described in detail in EXAMPLE 2), therebyestablishing a high likelihood that mobile device 105 and mobile device160 are operating within the same vehicle (and are thus subjected tosubstantially identical conditions). To further illustrate, being thatvarious mobile devices such as smartphones utilize different userinterfaces and button configurations, it can be advantageous in certainarrangements to compare inputs from one mobile device 105 with those ofanother mobile device 160 that is either identical to or at least highlycompatible with mobile device 105 (such as a device using the sameoperating system). Due to differences across various mobile devices andoperating systems, ensuring that mobile device 105 and mobile device(s)160 are similar (if not identical) ensures that the inputs received fromeach can be assumed to be highly comparable.

Additional examples of processing inputs from one device 105, 160against those of one or more other devices to identify one or moredetermination characteristics are provided below in EXAMPLE 2.

In addition, in certain arrangements it is preferable that the inputsfrom mobile device 105 and those of mobile device 160 that are to beprocessed against one another/compared are substantially synchronizedfrom a chronological standpoint. That is, it is preferable that each ofthe various inputs be associated with a particular time (and that thesource of such time be a central clock, such as a server, which cansynchronize the various devices, though it should be understood that inother arrangements one or more of devices 105, 160 can broadcast timingdata that enables the calibration of the various devices), therebyenabling the processing of inputs from mobile device 105 with inputsfrom mobile device 160 that correspond to the same point in time. Doingso ensures that the various inputs being processed/compared are highlycomparable, in that they reflect the operations of the various devices105 and 160 in response to the same events (e.g,accelerating/decelerating over the course of a driver). Additionalexamples and illustrations of such further processing operations areprovided below in EXAMPLE 3.

At step 227, processor 110 executing one or more of software modules130, including, preferably, determination module 170, receives an inputfrom vehicle data system 164, such as an on board diagnostic (OBD)computer or computing device (e.g., OBD-I, OBD-II, ECU, roll system,airbag system, and/or an ABS), preferably through communicationinterface 150. As noted above, vehicle data system 164 preferablyprovides data and/or information originating at the vehicle itself. Forexample, vehicle data system 164 can provide one or more inputs thatreflect various actions or events, such as a car's acceleration and/ordeceleration, steering, braking, and/or any other such car-relatedoperations. Such inputs can provide further insight into determining thein-vehicle role of a user of mobile device 105, as will be describedbelow.

Then, at step 228, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesan input of mobile device 105 against an input of vehicle data system164, in a manner similar to that described above with respect to step226. However, here an input of mobile device 105, such as various typingtendencies (as illustrated above) is processed against an input fromvehicle data system 164 that preferably pertains to an operation of acar (e.g., the car accelerating, braking, and/or swerving) and which isqualitatively different than the input of mobile device 105 becausevehicle data system 164 cannot necessarily detect the various stimuliperceptible to mobile device 105, owing in part to the fact that mobiledevice 105 is preferably not fixed relative to the car's coordinatesystem. As such, the various inputs (that is, the inputs from mobiledevice 105 and those from vehicle data system 164) are compared and/orsynchronized from a chronological standpoint, substantially in themanner described above with respect to step 226. In doing so, inputsfrom mobile device 105 can be processed against inputs from vehicle datasystem 164 (which, in turn, originate at the car itself), therebyenabling the association of various inputs from mobile device 105 withevents such as the accelerating, braking, and/or swerving of the car.Thus, following the typing tendencies example provided, if certainhighly erratic typing tendencies perceived at mobile device 160, occurjust prior and/or closely correlate to various driving operations(reflected in the inputs from vehicle data system 164) such asaccelerating, braking, and/or swerving, one or more user determinationcharacteristics can be identified with regard to the input(s) frommobile device 105, indicating that there is a high likelihood that thein-vehicle role of the user of mobile device 105 is a driver.

At this juncture, it can be appreciated that although several sectionsof the forgoing disclosure have referenced the processing and/orcomparison of various inputs against one another in context of inputsthat are qualitatively comparable (such as at steps 224 and 226, above,referring to the comparison of typing tendencies from various sources),in other arrangements various inputs that are not necessarilyqualitatively comparable (or, at least, do not appear to bequalitatively comparable). For example, in a manner similar to thatdescribed above with respect to step 223, an input of typing tendenciesfrom one source (such as mobile device 105) can be comparedwith/analyzed against an input of accelerations/decelerationsoriginating at mobile device 160. The respective inputs preferably havea timestamp to enable the chronological comparison between the inputs,as described in greater detail above with respect to step 226.

At step 230, processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factors, such as a probability, based on the variousdetermination characteristics, that the in-vehicle role of the user ofmobile device 105 is a driver and/or a probability that the in-vehiclerole of the user of the mobile device 105 is a passenger, substantiallyin the manner described in detail above with regard to step 230. Then,at step 240, the processor 110 executing one or more of software modules130, including, preferably, determination module 170, transforms anoperation state of the mobile device 105 and/or outputs at least oneoperation state based on the at least one determination factor, and/oroutputs at least one in-vehicle role of the user based on at least onedetermination factor, and/or outputs at least one in-vehicle location ofthe mobile device 105 based on at least one determination factor, and/oroutputs at least one result based on the at least one determinationfactor, as also described in detail above.

Turning now to FIG. 2C, a flow diagram is described showing a routine203 that illustrates a further aspect of a method for determining anin-vehicle role of a user of a mobile device 105 in accordance with atleast one embodiment disclosed herein. The process begins at step 210where an input is received from mobile device 105, and proceeds to step220 where the first input is analyzed. At step 230, a determinationfactor such as a probability is computed, based on the variousdetermination characteristics, as referenced above. Steps 210, 220, and230 have already been described above with reference to FIG. 2A and thuswill not be further elaborated upon here as their operation issubstantially identical to steps 210, 220, and 230 described above.

Then, at step 250, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, outputsone or more results based on the determination factor(s) computed atstep 230. Such results can include, but are not limited to, one or morefiles, notifications, and/or communications that contain and/or reflectoperations of the mobile device 105, and/or one or more operation statesof the first mobile device 105, and the outputting of such results canbe dependent upon a certain probability threshold, as described indetail herein. For example, in a scenario where mobile device 105 isconfigured to output results (such as that the in-vehicle role of a useris a driver/passenger) when the probability (that is, the reliability)of such results are greater than 75%, when mobile device 105 determineswith a probability of 80% that the in-vehicle role of a user of mobiledevice 105 is a driver, a corresponding notification can be outputtedreflecting such results. Thus, it can be appreciated that the referencedresults can be output based on the calculated probability that the userof mobile device 105 is a driver or that the user of mobile device 105is a passenger. It should be understood that the outputting referencedat this step can be employed in a number of ways depending on theparticular arrangement. For example, in certain arrangements thereferenced results can be transmitted to an external device orthird-party, such as a law enforcement agency, insurance company, and/orother device 160 (for example, a parent receiving results from a child'sdevice 105), via communication interface 150. It can be appreciatedthat, as referenced above with regard to step 240, the outputting ofsuch results to a law enforcement agency, insurance company, and/oranother device 160 can ensure that such entities are notified of thevarious operations and/or operation states of a particular mobile device105, especially when it has been determined that it is highly probablethat device 105 is being operated by a driver of a car. In anotherarrangement, such results can be outputted to mobile device 105 itselfin any number of ways, such as by logging the operations and/oroperation state(s) of mobile device 105 at times/intervals when it hasbeen determined, for instance, that there is a high probability that theuser of mobile device 105 is a driver. Irrespective of whether theresults are output to a third-party or to the device 105 itself, itshould be appreciated that the outputting of such results can provideinsight regarding the operations of the mobile device 105 at aparticular moment and/or interval, which can be utilized later, such asin investigating car accidents. For example, if a car accident occurs, alaw-enforcement agency can review such outputted results to determinewhether the driver was engaged in various distracting activities duringand/or near the time of the accident (e.g., mobile device 105 was beingused by driver with 93% certainty, was being used in a hand-held statewith 94% certainty, and was being used for texting with 100% certaintyat least 30 seconds prior to the crash). As such, it can be furtherappreciated in certain arrangements the various referenced results canbe outputted across any and/or all degrees of probability, therebyensuring a comprehensive log of a user results, reflecting the variousoperations and/or operation states throughout the course of operation ofthe mobile device 105.

In certain implementations, a device can be determined to be operated bya driver or a passenger based on one or more applications running at thedevice (and/or that are installed on the device but not necessarilyrunning). FIG. 43 is a flow diagram of a routine that illustratesaspects of one or more methods, such as those described in relation toone or more embodiments described herein. In various implementations,one or more aspects of the referenced method can be performed by one ormore hardware devices/components (such as those depicted in FIG. 1), oneor more software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4305 one or more operational aspects ofa user device can be identified. In certain implementations the one ormore operational aspects can include one or more applications executingat the mobile device. Moreover, in certain implementations the one ormore operational aspects can include one or more resources beingutilized at the mobile device. At 4310 the one or more operationalaspects can be processed, such as in order to determine one or morecharacteristics of a user of the user device. At 4315, one or moreoperations can be initiated, such as based on the one or morecharacteristics.

For example, a device determined to be within a moving vehicle that isrunning a SatNav application can be determined to be relatively morelikely to be operated by a driver than by a passenger. Moreover, basedon the resources that the device is using (e.g., whether Bluetooth ispaired on the device), it can be determined that it is more likely thata driver is operating the device, while if a headset is plugged into thedevice's headset jack and music is playing while the device isdetermined to be within a moving vehicle, it is more likely that apassenger is operating the device.

Turning now to FIG. 3, a flow diagram is described showing a routine 300that illustrates an aspect of a method for enabling, disabling and/ormodifying at least a feature of a mobile device 105 in accordance withat least one embodiment disclosed herein.

The process begins at step 310 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, monitors one or more inputs from one or more of sensors 145,software modules 130, user interface 172, operating system 176, and/orcommunication interface 150. As described in detail above with referenceto step 210, examples of such inputs include, but are not limited to, anacceleration input, a geographic location input, and/or one or moreinstances or user interaction (e.g., typing).

Then, at step 320, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170 defines anoperation signature based on the inputs monitored at step 310. Thedefined operation signature preferably reflects a normal operation stateand/or a range of normal operation states of the mobile device 105. Thatis, based on the various inputs monitored at mobile device 105, over adefined time interval (for example, a day, a week, and/or a month) anoperation signature or profile can be defined that reflects one or morevalues or ranges of values that have been identified as the normal orregular operation of the device 105, the normal or regular usage of thedevice 105 by a particular user, and/or the normal or regular usage ofdevice 105 and/or a series or class of such devices by a particular userand/or a series or range of users. For example, after monitoring inputsfrom the accelerometer 145A of mobile device 105 for a period of time, arange of normal acceleration inputs of the device 105 can be determined.Similarly, upon monitoring inputs from the user interface 172 of mobiledevice 105, a range of normal typing tendencies (e.g., typing speeds,typing consistency, etc., as described herein) can be determined. Thesevarious inputs can be used to define an operation signature for themobile device 105 that reflects the normal operation and/or operatingrange of the device 105. It should be appreciated that the referencedoperation signature is not limited to a single input or type of input,but rather in certain arrangements can be made up of signatures of twoor more types of inputs. For example, in one arrangement a normaloperation signature can be made up of a range normal accelerometerinputs together with a range of normal typing tendencies.

At step 330, processor 110 executing one or more of software modules130, including, preferably, determination module 170, further monitorsone or more second inputs from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150, substantially in the manner described abovewith respect to step 310.

Then, at step 340, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, processesone or more of the second input(s) (monitored at step 330) against oneor more of the operation signature(s) (defined at step 320). In doingso, processor 110 executing one or more of software modules 130,including, preferably, determination module 170, can identify a degreeof deviation and/or a degree of correlation between the second input(s)and the operation signature(s). By way of example, various typingpatterns and/or tendencies (referenced above) of mobile device 105 canbe processed against an operation signature reflecting a range of normaltyping tendencies of mobile device 105, as referenced above with respectto step 320 and described in detail herein. In doing so, processor 110can analyze and/or identify the degree to which the one or more secondinput(s) (monitored at step 330) deviate from the operation signature ofmobile device 105 (defined at step 320). Thus, continuing with theprovided example, even in a case where the monitored typing tendenciesof mobile device 105 are not necessarily highly inconsistent, from anobjective standpoint, upon processing such inputs against an operationsignature (such as an operation signature reflecting that the typingtendencies of the user of mobile device 105 are generally highlyconsistent/accurate), it can be revealed that the monitored typingtendencies/inputs actually deviate substantially from the mobiledevice's 105 operation signature. In this example, such a deviation fromthe operation signature (which reflects the normal and/or expectedoperation of mobile device 105) can indicate that the mobile device 105is being operated under conditions that distract the user frominteracting normally with the device 105, such as during driving.Similarly, in an alternative example, in a case where the monitoredtyping tendencies of mobile device 105 are relatively inconsistent, froman objective standpoint, upon processing such inputs against anoperation signature (such as an operation signature reflecting that thetyping tendencies of the user of mobile device 105 are also generallyinconsistent, such as in the case of a new user who is not adept attyping), it can be revealed that the monitored typing tendencies/inputs(which otherwise reflect significantly inconsistent typing tendencies)actually correlate substantially with the mobile device's 105 operationsignature. In such an example, the correlation with the operationsignature (which reflects the normal and/or expected operation of mobiledevice 105) can indicate that the mobile device 105 is actually beingoperated under relatively normal/consistent conditions, and thus shouldnot be assumed to be operated under distracting conditions, such asdriving, as may have otherwise been concluded based on the inconsistenttyping tendencies alone.

At this juncture, it should be noted that steps 310 and 320 can berepeated on a periodic and/or constant basis, in order to further refinethe operation signature defined at step 320. That is, it can beappreciated that in certain scenarios a user's interaction with mobiledevice 105 can change and/or improve over time (such as in the case of anew user whose typing skills gradually improve with repeated use ofdevice 105), and thus the operation signature of mobile device 105should be adjusted, modified, and/or refined accordingly. It can beappreciated that this process can be achieved in any number of ways. Inone arrangement, mobile device 105 can be configured to periodicallyreset its operation signature (such as every month), such that onlyrecent operations are accounted for in defining the operation signature.In other arrangements, further inputs that are monitored can be factoredinto and/or averaged with previously monitored inputs, thereby updatingan existing operation signature. In yet other arrangements, furtherinputs can be factored into and/or averaged with previously monitoredinputs, and the more recent inputs can be weighted to place greateremphasis upon them, thereby updating an existing operation signaturewhile accounting for the fact that more recent inputs are of greatervalue in defining an accurate operation signature of a mobile device105.

At step 350, processor 110 executing one or more of software modules130, including, preferably, determination module 170, adjusts one ormore operations of mobile device 105. Preferably, this adjustmentcorresponds to the degree of deviation and/or the degree of correlationbetween one or more monitored inputs (such as the input monitored atstep 330) and one or more operation signature(s) of mobile device 105(such as the operation signature defined at step 320). It should beunderstood that in certain arrangements, this adjustment is similar tothe transformation of the operation state of mobile device 105 discussedin detail above with respect to step 240, and/or the outputting of oneor more results discussed in detail above with respect to step 250. Forexample, in certain arrangements, processor 110 can coordinate thedisabling of one or more features of the mobile device 105, such as thedisabling of any and/or all features that enable the entry of text intomobile device 105, while in other arrangements notifications (such aswarning notifications) can be provided at or transmitted to mobiledevice 105. Various other examples of adjustments to one or moreoperations of mobile device 105 are described in greater detail abovewith reference to steps 240 and 250.

As also described in detail above with respect to step 240, it should benoted that various of the adjustments employed at step 350 can becustomized and/or configured in relation to various degrees ofcorrelation and/or deviation identified at step 340. Thus, it can beappreciated that certain adjustments of the operation of mobile device105 (for example, notifying law enforcement authorities) may only beappropriate when a high degree of deviation from a normal operationstate (that is, from the operation signature) is identified (and,preferably, further that such a deviation is indicative of restricted orprohibited activity on the part of the user of mobile device 105). Otheradjustments, such as providing a notification at mobile device 105, maybe appropriate even for lower degrees of correlation/deviation, asdescribed in detail above.

In certain implementations, information regarding whether and how adevice user uses his/her device, such as when in a moving vehicle, canbe measured and/or recorded, whether or not the device user isdetermined to be the driver (or irrespective of a likelihood that thedevice user is the driver). Such technologies/techniques can be used,among other things, to log and analyze how large a “distracted driving”problem the device user has, i.e., based on how much and in what waysthe device's usage deviates from a particular device usage policy (e.g.,a state or federal law, a company policy, a parental policy, etc.) inconjunction with various determinations pertaining to the identity ofthe user (e.g., as a driver of a vehicle).

In certain implementations, such technologies can utilize informationobtained directly from the device (e.g., information about calls made orreceived, texts made or received, applications used, URLs visited,intermediate or final sources or destinations of data transmissions,device movement information, location information, network connectivityor visibility information, GPS, accelerometer, etc.) and/or informationobtained from third parties (e.g., mobile server providers, telematics,etc.).

The referenced information can also be saved to the device and/or to aremote server.

Turning now to FIG. 4, a flow diagram is described showing a routine 400that illustrates an aspect of a method of determining at least one of anin-vehicle role of a user of a first mobile device and/or a handheldstate of the first mobile device and/or a vehicle class of a vehiclecontaining the first mobile device using a central machine in accordancewith at least one embodiment disclosed herein. As will be described ingreater detail below, various of the steps and operations that make uproutine 400 share substantial similarities to those described above inconnection with FIGS. 2A-C and 3. However, it should be understood thatwhile FIGS. 2A-C and 3 principally concern determinations occurring atmobile device 105, routine 400 is primarily directed to determinationsperformed at central machine 168, as will be described in greater detailbelow. It should be further noted that, as described in greater detailbelow, while any one of the particular steps, operations, and/orfunctions are described throughout the present disclosure as beingperformed at and/or upon a particular machine or device (such as mobiledevice 105, mobile device 160, and/or central machine 168), suchdescription should be understood as being exemplary and/or illustrativeand not limiting. Accordingly, it can be appreciated that any and allsteps, operations, and/or functions described herein with regard to aparticular device and/or machine (such as central machine 168) should besimilarly understood to be similarly capably of employment at anotherdevice and/or machine (such as mobile device 105), substantially in themanner described herein, without departing from the scope of the presentdisclosure.

The process begins at step 410 where processor 4110 of central machine168 (depicted in FIG. 1) executing one or more of software modules 4130,including, preferably, determination module 4170, receives (preferablythrough communication interface 4150) a first notification from mobiledevice 105, the first notification preferably corresponding to an inputoriginating from one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150of mobile device 105. As described in detail above with respect to step210, the first input originates from one or more identifying events thatare perceptible to at least one of sensors 145, user interface 172,operating system 176, and/or communication interface 150 of mobiledevice 105, such as an acceleration input perceived by accelerometer145A, a change in geographic location input perceived by GPS receiver145C, and/or one or more instances or user interaction (e.g., typing)detected by user interface 172. A notification, such as a computerreadable file containing information that reflects the input itself aswell as information that is pertinent to the input (such as the time,date, and a unique identifier such as a MAC address of mobile device105) is preferably generated by mobile device 105 based on the input,and is transmitted by communication interface 150 of mobile device 105to central machine 168, preferably via communications network 166. Asnoted above, it should be recognized that while FIG. 1 depicts centralmachine 168 communicating with mobile device 105 via network/Internet166, it should be understood that in other arrangements central machine168 communicates with mobile device 105 directly, such as through adirect Bluetooth pairing and/or through an ad-hoc wireless network.

Then, at step 420, processor 4110 of central machine 168 executing oneor more of software modules 4130, including, preferably, determinationmodule 4170, analyzes at least the first notification to identify one ormore determination characteristics, such as one or more of userdetermination characteristics and/or one or more handheld statecharacteristics and/or one or more vehicle determination characteristicswithin the notification. As described in detail above with respect tostep 220, user determination characteristics are one or more aspectsoriginating at and/or derived from one or more input(s) and/ornotification(s) that provide insight regarding the in-vehicle role,and/or identity of the user that is exerting control over and/orotherwise associated with a mobile device, such as mobile device 105.Similarly, handheld state characteristics are one or more aspectsoriginating at and/or derived from one or more input(s) and/ornotification(s) that provide insight regarding the handheld state of amobile device, such as mobile device 105, such as whether mobile device105 is being operated by a user in a handheld or non-handheld state (forexample, various angles and/or sudden changes perceived by gyroscope145B can indicate that mobile device 105 is being operated in a handheldstate by a user). It can thus be appreciated that while the underlyinganalysis performed at the present step 420 and at step 220, as describedabove, are substantially similar, here the analysis is performed bycentral machine 168 based on notifications received from mobile device105, while at step 220 the analysis is preferably performed by mobiledevice 105 itself. Having this analysis performed at central machine 168(as opposed to at mobile device 105, from which the notificationanalyzed at this step originates) provides several advantages in certainscenarios over having the analysis performed at mobile device 105, asdescribed at step 220. For example, the analysis performed at thepresent step can be quite resource intensive, and shifting this analysisto central machine 168 ensures that the system resources of mobiledevice 105 remain relatively free. Additionally, in certain arrangementscentral machine 168 can be operated by a law enforcement agency, and, assuch, a centralized approach, such as the one described with respect toFIG. 4, can provide such an agency with the ability to monitor and/oradjust the operational capacity of mobile device 105 as necessary, aswill be described in greater detail below. Moreover, in certainscenarios this centralized approach can be easier to implement withrespect to regulatory compliance and preventing tampering. It isexpected that both regulatory authorities who are interested inimplementing a solution such as that described with reference to FIG. 4are more likely to succeed in obtaining compliance from mobile devicemanufacturers and/or mobile communications providers when requiring asolution that primarily only requires, from the standpoint of the mobiledevice 105, periodic notification transmissions from mobile device 105to central machine 168. In addition, such a solution can be moredifficult for users to manipulate, modify, and/or ‘hack,’ given that theprimary analysis is performed by central machine 168, as opposed tomobile device 105.

At step 430, processor 4110 of central machine 168 executing one or moreof software modules 4130, including, preferably, determination module4170, computes one or more determination factor(s), such asprobabilities, based on the determination characteristics identified atstep 420. It should be understood that, for instance, based on theparticular inputs upon which a notification (which is analyzed at step420) is based, various user determination characteristics and/orhandheld state characteristics are generated. For example, as referencedabove, in certain arrangements user determination characteristics areidentified (such as typing tendencies, as referenced above), while inother arrangements handheld state characteristics (such as one or moreangles detected by mobile device 105, as referenced above) can beidentified, while in yet other arrangements both user determinationcharacteristics and handheld state characteristics can be identified. Inany event, at step 430, one or more probabilities are computed bycentral machine 168, reflecting a probability that the in-vehicle roleof the user of mobile device 105 is a driver, a probability that thein-vehicle role of the user of the mobile device 105 is a passenger, aprobability that the handheld state of the mobile device 105 ishandheld, and/or a probability that the handheld state of the mobiledevice 105 is non-handheld, all in a manner substantially similar tothat described in detail above with respect to step 230. It should beunderstood that, as described in detail above, in certain arrangementsthe user determination characteristics and/or handheld statecharacteristics identified at step 420 can provide varying degrees ofcertitude as to the identity/role of a user and/or the handheld state ofmobile device 105. Accordingly, it should be appreciated that becauseranges exist across the spectrum of a particular user determinationand/or handheld state characteristic (such as typing consistency and/ordevice angle), a probability that an in-vehicle role of the user ofmobile device 105 is a driver/passenger and/or a probability that ahandheld state of mobile device 105 is handheld/non-handheld preferablyreflects a degree of certainty across such a probability spectrum, asdescribed in detail above.

Then, at step 440, processor 4110 of central machine 168 executing oneor more of software modules 4130, including, preferably, determinationmodule 4170, adjusts an operational capacity of mobile device 105 basedon the one or more determination factor(s), such as at least one of theprobabilities computed at step 430, substantially in the mannerdescribed in detail above with respect to step 240. However, it shouldagain be understood that while the description pertaining to step 240above relates to adjustments and transformations initiated by mobiledevice 105 upon itself, here the adjustments to the operation of mobiledevice 105 are initiated by central machine 168. For example, in certainarrangements central machine 168 can transmit an operation command, suchas a command in the form of one or more notifications, messages, and/orinstructions that reflect various adjustments that are to be made to theoperational capacity of mobile device 105, and such adjustments can thenbe applied to mobile device 105 upon its receipt of the transmittedoperation command(s), and/or their application/execution, effectingsimilar and/or identical results as those described in detail above withrespect to step 240 (e.g., providing notifications at mobile device 105,restricting operation of mobile device 105, and/or transmittingnotifications from mobile device 105 to third parties). In otherarrangements, central machine 168 can adjust the operational capacity ofmobile device 105 based primarily and/or exclusively on adjustments madeat and/or by central machine 168 which, in turn, preferably effect orotherwise adjust the operational capacity of mobile device 105. Forinstance, in an arrangement where central machine 168 is controlled by amobile communications provider such as a cellular communicationsprovider, an adjustment can be implemented at central machine 168whereby one or more of the services provided by mobile communicationsprovider to mobile device 105 (such as phone, SMS, and/or data services)can be interrupted and/or otherwise adjusted or modified, therebyeffecting the operation of mobile device 105 through an adjustmentoccurring at central machine 168 based on the probability computed atstep 430. It should be noted that in other arrangements, substantiallysimilar adjustments can be implemented upon and/or through one or moreservice providers that provide one or more services, whether directly orindirectly, to mobile device 105. By way of illustration, various voiceover IP (VoIP) providers, such as Skype, enable users to achieve voicecommunications (akin to telephone calls) over data connections (such asan internet connection). By way of further illustrations, the Viber appenables similar SMS capabilities over an internet connection. In anyevent, it should be understood that the methods and systems disclosedherein can be configured such that any necessary adjustment can beimplemented upon and/or through the requisite service provider (forexample, by limiting the calling capabilities of Skype and/or the SMScapabilities of Viber) substantially in the manner described in detailabove.

At step 450, processor 4110 of central machine 168 executing one or moreof software modules 4130, including, preferably, determination module4170, outputs one or more results and/or operation states of mobiledevice 105 based on the one or more determination factor(s), such as theprobability or probabilities computed at step 430, substantially in thesame manner as described in detail above with respect to step 250. Butagain, as noted above, it should be understood that while thedescription provided above with respect to step 250 pertains to one ormore operations performed at mobile device 105, step 450 primarilypertains to operations initiated and/or performed by central machine168. Accordingly, it can be appreciated that the one or more operationstate(s) outputted by central machine 168 reflect the operation state(s)of mobile device 105 (for example, that the device is being used in ahandheld state and/or that the device is being used by a driver). Asnoted in detail above with respect to step 250, the outputting of theoperation state(s) can be further based upon one or more determinationfactor(s), such as one or more probabilities computed at step 430, whichreflects the likelihood or degree of certainty that a user of mobiledevice 105 is a driver/passenger and/or that mobile device 105 is beingused in a handheld/non-handheld state. As also noted in detail above, incertain arrangements the operation state of mobile device 105 can beoutputted by central machine 168 to an external device or third-party,such as a law enforcement agency, insurance company, and/or other device160, via communication interface 4150. Such functionality can beadvantageous in jurisdictions where administrative regulations recommendand/or require that entities such as mobile communications providersprovide information to law enforcement agencies that reflects theunauthorized usage of mobile devices such as mobile device 105 while theuser of the device is driving. Similarly, such functionality can beadvantageous to insurance companies when processing an insurance claim.Even in situations where the user of a mobile device, such as mobiledevice 105, is uncooperative in providing information to the insurancecompany, and/or in situations where the mobile device associated with aninvolved party is no longer available or has been destroyed, centralmachine 168 (which receives and retains the various pertinentnotifications/inputs provided by the various devices such as mobiledevice 105) can output the necessary data, such as the operation stateof mobile device 105, thereby assisting the insurance company to makenecessary decisions regarding the validity of a particular insuranceclaim.

Turning now to FIG. 5, a flow diagram is described showing a routine 500that illustrates an aspect of a method of determining a vehicle class ofa vehicle using a first mobile device in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, determining the vehicle class of a particular vehicle can providefurther insight and accuracy in the determination of an in-vehicle roleof a user of a mobile device. In addition, it should be understood thatthe various steps and/or operations that make up routine 500 sharesubstantial similarities to those described above in connection withFIGS. 2A-C and 3-4.

The process begins at step 510 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150.

Then, at step 520, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input to identify one or more vehicle determinationcharacteristics within the first input. As will be described in greaterdetail below, vehicle determination characteristics are one or moreaspects originating at and/or derived from an input that provide insightregarding the vehicle class within or upon which and/or in relation tomobile device 105 is traveling.

Upon identifying one or more vehicle determination characteristics basedon the analysis of an input, at step 530 processor 110 executing one ormore of software modules 130, including, preferably, determinationmodule 170, computes at least one determination factor based on thevehicle determination characteristic(s), such as a probability that thevehicle corresponds to a particular vehicle class.

Then, at step 550, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, outputs avehicle class based on the one or more determination factor(s), such asthe probability or probabilities computed at step 530.

It should also be noted that, in certain arrangements, the processor 110executing one or more of software modules 130, including, preferably,determination module 170, can transform an operation state of mobiledevice 105 based in whole or in part on the determination factor(s),such as the probability computed at step 530. This operation can befurther appreciated when employed in conjunction with a determination ofan in-vehicle role of a user of mobile device 105, such as that depictedin FIGS. 2A-C and described in detail above. For example, in certainarrangements, upon determining (preferably to a certain minimumprobability) that a mobile device 105 is traveling within a certainclass of vehicle, there can be little need to further determine thein-vehicle role of the user of the device 105 (e.g., if the vehicle isan airplane, all device usage can be prohibited, irrespective of aparticular user's in-vehicle role). By way of further example, in otherarrangements, a transformation (substantially similar to that describedin detail above with respect to step 240) can be employed based uponboth the computed probability that mobile device 105 is traveling in acar, together with the computed probability (such as that described indetail above with respect to step 230) that the in-vehicle role of auser of mobile device 105 is a driver. In such a scenario, processor 110can coordinate various transformations and/or adjustments to theoperation(s) of mobile device 105, as described in detail above withrespect to step 240. As also noted above, in certain arrangementsvarious of the referenced transformations can be employed only wheneither one or both of the probabilities pertaining to the vehicle classwithin which mobile device 105 is traveling and/or the in-vehicle roleof the user of mobile device 105 is a driver meet and/or exceed acertain minimum threshold.

Turning now to FIG. 6, a flow diagram is described showing a routine 600that illustrates an aspect of a method of determining a handheld state amobile device in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 600 share substantialsimilarities to those described above in connection with FIGS. 2A-C, 3,4, and 5. However, it should be understood that while at least FIG. 4principally concerns determinations occurring at central machine 168,routine 600 is primarily directed to determinations performed at mobiledevice 105, as will be described in greater detail below.

The process begins at step 610 where processor 110 executing one or moreof software modules 130, including, preferably, determination module170, receives a first input from one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150. Preferably, the first input originates fromone or more identifying events that are perceptible to at least one ofsensors 145, user interface 172, operating system 176, and/orcommunication interface 150. As described in detail above with respectto step 210, the first input originates from one or more identifyingevents that are perceptible to at least one of sensors 145, userinterface 172, operating system 176, and/or communication interface 150of mobile device 105, such as an acceleration input perceived byaccelerometer 145A and/or a change in orientation input perceived bygyroscope 145B. It should be noted that in certain arrangements a seriesof inputs (such as a number of acceleration inputs over a certain periodof time) and/or a combination of inputs (such as a number ofacceleration inputs and orientation inputs over a period of time) arereceived, such as one or more inputs that reflect the incidence ofshaking or vibration at mobile device 105.

Then, at step 620, processor 110 executing one or more of softwaremodules 130, including, preferably, determination module 170, analyzesat least the first input to identify one or more handheld statecharacteristics within the notification. As described in detail abovewith respect to step 420, handheld state characteristics are one or moreaspects originating at and/or derived from one or more input(s) thatprovide insight regarding the handheld state of a mobile device, such asmobile device 105, such as whether mobile device 105 is being operatedby a user in a handheld or non-handheld state. For example, variousorientations and/or sudden changes perceived by gyroscope 145B(preferably, in certain scenarios, in combination with one or moreinputs from various other sensors 145 such as accelerometer 145A, GPS145C, and/or magnetometer 145E) can indicate that mobile device 105 isbeing operated in a handheld state by a user. By way of further example,a relatively constant pattern of inputs from accelerometer 145A and/orgyroscope 145B can indicate that mobile device 105 is positioned in arelatively stable manner, thus indicating that it is being operated in anon-handheld state.

At step 630, processor 110 executing one or more of software modules130, including, preferably, determination module 170, computes one ormore determination factor(s), based on the handheld state determinationcharacteristic(s), such as a probability that that the handheld state ofmobile device 105 is handheld, or that the handheld state of mobiledevice 105 is non-handheld. By way of example, based on a series ofaccelerometer 145A and gyroscope 145B inputs, the pattern of whichindicates ongoing vibration and/or movement, it can be computed thatthere is a high probability (e.g., greater than 90%) that mobile device105 is being operated in a handheld state. This is because a user ofhandheld mobile device 105—and particularly a driver who is furtherdistracted by his/her driving responsibilities—is liable to produce farmore vibration/shaking that is perceptible by mobile device 105,especially as compared to a non-handheld device that is stationed in adock, for instance. In any event, at step 630, such probabilities arecomputed, reflecting a probability that the handheld state of the mobiledevice 105 is handheld, and/or a probability that the handheld state ofthe mobile device 105 is non-handheld, in a manner substantially similarto that described in detail above with respect to steps 230 and 430. Itshould be understood that, as described in detail above, in certainarrangements the handheld state characteristics identified at step 620can provide varying degrees of certitude as to the handheld state ofmobile device 105. Accordingly, it should be appreciated that becauseranges exist of a particular handheld state characteristic (such asdevice shake patterns), a probability that a handheld state of mobiledevice 105 is handheld/non-handheld preferably reflects a degree ofcertainty across such a probability spectrum, as described in detailabove.

At step 650, processor 110 executing one or more of software modules130, including, preferably, determination module 170, outputs one ormore handheld states of mobile device 105 based on the one or moredetermination factor(s), such as the probability or probabilitiescomputed at step 630, substantially in the same manner as described indetail above with respect to steps 250, 450,and 550. For example, if, atstep 630, it is computed that it is 90% likely that mobile device 105 isbeing operated in a handheld state, at step 650 a notification can beprovided at mobile device 105 indicating that it has been determinedthat the device is being so operated. In certain arrangements such anotification can further include a suggestion/instruction that the userof the device 105 refrain from further use of the device, in deferenceto regulatory guidelines. In other arrangements, the handheld state ofmobile device 105 can be output to a third-party, such as a lawenforcement agency, under appropriate circumstances. Additionally, asnoted in detail above with respect to step 250, such outputting can, incertain arrangements, be contingent upon a certain minimum probabilitybeing computed (e.g., a 90% or greater probability that a mobile device105 is operating in a handheld state), while in other arrangements thehandheld state can be outputted across any and/or all degrees ofprobability.

Described herein in various implementations are techniques (includingmethods, systems, etc.) that are operative to improve the accuracy ofvarious determinations, including determinations pertaining to whether adevice is in a particular context (or not) and/or reducing the powerconsumed/expended (such as by the device) in order to make suchdetermination(s). Such techniques can be advantageous, for example, insituations in which such determinations are to be made repeatedly overextended periods of time. It should be understood that, in certainsituations, particular sources of information that may otherwise beconsidered/analyzed in order to make certain context-baseddeterminations/decisions may not be available. For example, in variousurban locations or in certain climatic conditions (e.g., duringcloudy/stormy weather) GPS information may not be available, and suchinputs are thus unavailable to be used in determining movement and/orspeed by/in relation to a device. It can also be appreciated that usageof such sensors can consume substantial amounts of power at the device.As such, it can be advantageous (such as in circumstances in which oneor more sensors/inputs are unavailable or unreliable) to employdetermination techniques that use different/alternative sources ofinformation (such as other sensors) in order to determine a context ofthe device.

FIG. 27 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2705, one or more power chargingaspects can be determined, such as in relation to a user device. At2710, the one or more power charging aspects can be processed. In doingso, a context of the user device can be determined. At 2715 one or moreoperations can be initiated. In certain implementations, such operationscan be initiated based on the context. Moreover, in certainimplementations, such operations can be initiated in relation to theuser device.

FIG. 28 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2805, one or more indications can bereceived. In certain implementations each of the one or more indicationscan correspond to a perception of one or more access points. Moreover,in certain implementations each of the one or more indications can beingassociated with an operational context of a device. At 2810, the one ormore indications can be processed. In certain implementations, suchindications can be processed in order to determine one or morecharacteristics associated with one or more respective perceptions of atleast one of the one or more access points. At 2815, the one or morecharacteristics can be associated with one or more operational contexts.At 2820, one or more operations can be initiated. In certainimplementations, such operations can be initiated based on adetermination of at least one of the one or more characteristics inrelation to a user device. Moreover, in certain implementations suchoperations can be initiated in relation to the user device based on atleast one of the one or more operational contexts.

FIG. 29 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 2905, one or more operationalcharacteristics of a device can be identified. At 2910, one or morecontextual determination methods can be selectively employed, such as inrelation to the device. In certain implementations, such determinationscan be employed based on the operational characteristics. At 2915, aninapplicability of at least one of the one or more contextualdetermination methods can be determined, such as in relation to thedevice. In certain implementations such an inapplicability can bedetermined based on at least one of the operational characteristics.

FIG. 30 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3005 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. In certain implementations, atleast one of the one or more indications can include one or morelocations, such as those corresponding to the at least one of the one ormore access points. At 3010, the one or more indications can beprocessed, such as in relation to one or more access point records. Indoing so, one or more characteristics of at least one of the one or moreaccess points can be determined. In certain implementations, the one ormore characteristics can include (a) nomadic or (b) stationary. Incertain implementations, the one or more locations can be processed,such as in order to determine a locational variability, such as withrespect to the at least one of the one or more access points. In certainimplementations, the locational variability can include a differencebetween (a) a location associated with a connection to the at least oneof the one or more access points and (b) a location associated with adisconnection from the at least one of the one or more access points. At3015, a context of the user device can be determined. In certainimplementations, such a context can be determined based on the one ormore characteristics. In certain implementations, the context caninclude at least one of: (a) within a vehicle, (b) not within a vehicle,(c) within a trip, or (d) not within a trip. In certain implementations,it can be determined that the user device is at least one of (a) notwithin a vehicle or (b) not within a trip, such as based on adetermination that the user device perceived a stationary access pointthroughout a chronological period. In certain implementations, a contextof the user device can be determined, such as based on the locationalvariability.

FIG. 31 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3105 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. At 3110, the one or moreindications can be processed, such as in order to determine avariability with respect to the one or more indications. In certainimplementations, the variability can include a quantity of distinctaccess points perceived during a chronological period. At 3115, acontext of the user device can be determined, such as based on thevariability.

FIG. 32 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3205 one or more indications can bereceived. In certain implementations, each of the one or moreindications can correspond to a perception of one or more access points,such as in relation to a user device. At 3210, the one or moreindications can be processed, such as in order to determine a quantityof access points perceptible to the user device. At 3215, a context ofthe user device can be determined, such as based on the quantity. Incertain implementations, the context can include (a) an urban locationor (b) a rural location. At 3220, a trip determination threshold can beselected, such as with respect to the user device. In certainimplementations, the trip determination threshold can be selected basedon the context.

FIG. 44 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4405 one or more indications can bereceived, each of the one or more indications corresponding to aperception of one or more access points in relation to a user device. At4410, the one or more indications can be processed, such as to determineone or more characteristics of at least one of the one or more accesspoints. At 4415, a context of the user device can be determined, such asbased on the one or more characteristics. At 4420, one or morecharacteristics can be associated with one or more operational contexts.At 4425, one or more operations can be initiated, such as based on adetermination of at least one of the one or more characteristics inrelation to a user device. In certain implementations, the one or moreoperations can be initiated in relation to the user device based on atleast one of the one or more operational contexts. At 4430, a tripdetermination threshold can be selected with respect to the user device,such as based on a context.

FIG. 45 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4505 one or more inputs associated witha user device can be processed, such as to determine one or moremobility characteristics of the user device. At 4510, a context of theuser device can be determined, such as based on a determination that theone or more mobility characteristics comprise mobile operation and donot comprise operation consistent with walking.

FIG. 46 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4605 an indication can be received,corresponding to a perception of a nomadic access point in relation to auser device. At 4610, a quantity of devices with respect to which thenomadic access point is perceptible can be determined. At 4615, acontext of the user device can be determining, such as based on thequantity.

By way of illustration, various techniques described herein can pertainto determinations as to whether or not a device is present/operational‘within a vehicle’ (e.g., a moving vehicle) and/or ‘within a trip’(e.g., a trip within a moving vehicle) (it should be noted that suchterms can be used interchangeably). In doing so, various aspects of thepower consumed/expended by a device (such as in order to make one ormore of the referenced determinations) can be reduced. Moreover, one ormore of the referenced techniques can also be implemented to determineor otherwise detect other contexts while consuming/expending relativelyless power, e.g., determining the in-vehicle role of a user of aparticular device, whether or not a device is present within a class oron school grounds, what mode/class of transportation/vehicle the deviceis present within (e.g., car, train, bus, bicycle, walking, etc.),whether or not the user is a vulnerable road user, and more.

In one implementation, information related to one or more aspects of thebattery and/or the power consumption of a device (e.g., whether thedevice is connected to power, the voltage across the battery of thedevice, the charge level and/or the battery temperature level of thebattery of the device) and/or changes thereto over time (e.g.,variability), can be used to determine whether the device is in avehicle.

For example, being that device batteries are likely to charge relativelyless quickly when connected to power within a vehicle than suchbatteries charge when plugged into a wall outlet (in light of thegenerally lower amperage of car chargers as compared to wall chargers),a determination that the charge level of a battery that is connected topower is increasing relatively slowly can indicated an increasedlikelihood that the device is present within a vehicle.

Moreover, in certain implementations the referenced technique(s) canalso incorporate aspects relating to the power being consumed by thedevice (e.g., in order to operate). For example, with respect to adevice that is connected to a power source and whose battery level isincreasing relatively slowly and is not consuming/expending significantamounts of power (that might otherwise account for such a relativelyslow battery level increase, such as applications running, screen state,GPS, Bluetooth, WiFi etc., sensors sampled), it can be determined thatsuch a device is relatively likely to be present within a vehicle(rather than being connected to a wall outlet). In yet furtherimplementations, such technique(s) can further incorporate variouscomparisons and/or machine learning techniques with respect tocharacteristics pertaining to the battery of a device (e.g., in relationto the performance/operation of the specific battery and/or the specificdevice and/or across a population of identical and/or similar/comparablemodel batteries and/or devices over time).

In certain implementations a variability in the rate at which a batterycharges can be used to determine a context in which a device isoperating (e.g., within a vehicle). Such determinations can be madebased on the variability in the rate at which the battery of a devicecharges, as a device that is connected to a car charger is relativelymore likely to display a relatively more variable battery charge ratethan a device connected to a wall outlet.

In another implementation, one or more aspects of a context within whicha device is present/operating can be determined based on the voltageacross a battery of the device and/or changes thereto. Suchdeterminations can be made, for example, based on the fact that thevoltage across a battery of a device that is connected to a car chargeris likely to exhibit relatively more variability than that of a deviceconnected to a wall outlet. In another example, various determinationscan be performed in order to identify/distinguish between various typesof power charge sources such as solar battery chargers and fixed wallchargers, based on the variability of the power from such sources (e.g.,a power source providing a relatively smaller current, a relatively morevariable current, and/or a current having a relatively more variablevoltage, can be determined to be relatively more likely to be presentwithin a vehicle, and vice versa) that they are able to provide to thedevice battery.

In another implementation, various determinations pertaining to thecontext within which a device is present/operating (e.g., within avehicle) can be achieved based on the temperature of a battery of thedevice. Moreover, and changes in such temperature(s) can be used todetermine one or more contexts of the device (e.g., whether the deviceis within a vehicle). Such determination(s) can be made, for example, inlight of the fact that the temperature of a device that is connected toa car charger is likely to exhibit different characteristics (e.g., moreextreme temperatures) than those exhibited by/observed in relation to adevice connected to a wall outlet.

Moreover, in certain implementations one or more determinationspertaining to a hands-free state of a device (e.g., where the device ispositioned/held within a vehicle) can be made based on one or moreaspects of the power connection status of the device (i.e.,). Forexample, it can be appreciated that a device that is connected to apower source is relatively more likely to be operated by a driver thanby a passenger (in light of the fact that, for example, a vehicle isrelatively more likely to have one or more a power connections that arecompatible with a device operated by a driver, and the locations suchpower sources, such as a cradle/dock having a power connection, isrelatively more likely to be positioned in closer proximity to a driverthan a passenger, etc.).

In certain implementations, when a device is connected to a power sourceand its context (e.g., within a vehicle vs. outside of a vehicle, withinschool grounds vs. outside of school grounds, etc.) has been identifiedand/or can be determined, one or more further determinations can be madewith respect to the ongoing state/status of such a device. For example,it can be determined that such a device is relatively likely to remainwithin or otherwise maintain the same/comparable context at least untilthe device is no longer connected to a power source. Accordingly, incertain implementations, having determined that a device is connected toa power source, one or more instance(s) (e.g., a “short burst”) ofadditional determination techniques (e.g., contextual determinations,such as those described herein), such as those that may entail higher oradditional power consumption, can be initiated or otherwise employed. Indoing so, a determination of the context within which a device ispresent/operating can be achieved initially (i.e., upon connecting thedevice to a power source) such that, having identified/determined such acontext, various aspects of the power consumption of the device can bereduced (e.g., over the medium and long terms). For example, havingdetermined that a particular device is connected to a power source, oneor more sensors of the device (e.g., GPS, WiFi radio, cellular radio,Bluetooth radio, accelerometer, gyroscope, etc.) can be turnedon/activated, such as for a period of time, in order to obtain/receiveone or more inputs based upon which it can be determined whether thedevice is (or is not) present/operating within a vehicle. Based on adetermination that the device is not present/operating within a vehicle,it can be further determined that the device is subsequently notpresent/operating within a vehicle as long as and/or at least until suchtime as the device is determined to no longer be connected to a powersource (and/or connected to the power source with respect to which thedevice was initially connected). Based on a determination that thedevice is present/operating within a vehicle, it can be furtherdetermined that such a state/status is likely continue, and thus thatthat the device is to continue to be present/operating within thevehicle, at least until such time as is the device is determined to nolonger be connected to a power source (and/or connected to the powersource with respect to which the device was initially connected).

It can be appreciated that one or more of the techniques describedherein operate based on the assumption that power sources (with respectto which the various determinations are computed) are non-nomadic (i.e.,that such power sources/supplies are fixed in a particular location).Accordingly, while in certain situations nomadic power sources/suppliescan also implemented (e.g., external batteries, portable power sources,etc.), the use of such nomadic power sources can be determined/detectedand/or otherwise accounted for in a number of ways. For example, theusage of such nomadic power sources can be determined based on the levelof current or voltage identified at the device/batter (and/or changesthereto), and/or via the magnetometer of the device (and/or changesthereto), and/or based on one or more movement patterns that can beidentified as being consistent with the use of a heavier device, as canbe determined based on one or more inputs originating from variousmotion sensors of the device (e.g., accelerometer, gyroscope).Additionally, such nomadic power sources are relatively less commonand/or can entail various barriers to user adoption (e.g., cost, size,weight, being cumbersome, etc.). Moreover, one or more of the referenceddeterminations can be accumulated/maintained over time, such as withrespect to a particular device, a user/user account associated with adevice, etc. As such, a device and/or a user/user account that has beendetermined (such as on an ongoing basis) to utilize a nomadic powersupply, the referenced techniques (which, for example, determine acontext of a device based upon a power connection state/status of thedevice) can be utilized relatively more selectively and/or not at allwith respect to such devices.

In certain implementations, based on a determination that a device isconnected to a power source, a scan of WiFi access points that areperceptible to the device can be initiated or otherwise performed, suchas at one or more intervals. In doing so, the number/quantity of and/oridentities (e.g., service set identifiers or ‘SSIDs’) associated withWiFi access points that are subsequently perceptible at the device canbe compared to an initial/previous number/quantity of and/or identitiesassociated with WiFi access points perceptible at the device. In doingso, a determination can be made with respect to whether or not (and/orwhen) the device is moving, such as is described in greater detailherein. For example, in a scenario where access points A, B and C areperceptible at a device, and at a subsequent time only access points D,E and F are visible, it can be determined that it is relatively likelythat the device has moved (on account of the changing identities of theaccess points perceptible at the device).

Moreover, scenarios can arise whereby, at one time/interval there wereno (or relatively fewer) access points perceptible, and at a laterinterval there are one (or relatively few new/additional) access pointsvisible. It can be appreciated that, in such scenarios, determinationspertaining to whether the device has moved may be relatively lessaccurate (in light of the fact that a single newly perceived accesspoint may have just been turned on despite the fact that the deviceremains stationary). Accordingly, in certain implementations one or moretimestamp(s) contained/embedded within the access point beacon can beused to determine an uptime of the access point. Based on adetermination that the uptime of the access point is relatively low, itcan be further determined that the access point is likely to have beenturned on relatively recently and the referenced change(s) with respectto the perception of various access point(s) under such circumstancesmay thus not provide accurate determinations with respect to themovement of the device. However, based on a determination that theuptime of the access point is relatively high, the referenced change(s)with respect to the perception of various access point(s) can providerelatively accurate determinations with respect to movement of thedevice, as described herein.

In certain implementations, the context within which a device ispresent/operating (e.g., within a car vs. at an office vs. at home) canbe determined in relation to various aspects of the powerconnectivity/connection associated with the device, by using one or moremachine learning techniques (as are known to those of ordinary skill inthe art) to identify, such as over time, one or more patterns,properties, and/or characteristics associated with various powersources/chargers that the device connects to and/or associating suchpatterns, properties, and/or characteristics with one or more contexts.That is, it can be appreciated that many users can utilize differentpower sources/chargers in different locations (e.g., a USB charger atwork, a cigarette lighter charger in the car and a wall charger athome). Such power sources can have different electrical properties(current, voltage, etc.) that can be perceived at/in relation to thedevice (e.g., USB charger in the office may charge the battery of aparticular device at 240 mAh, thereby charging the battery at a rate of0.2%/minute , while a car charger may charge the battery at 600 mAh,thereby charging the battery at a rate of 0.5%/minute, and an AC wallcharger at home may charge the battery at 1200 mAh, thereby charging thebattery at a rate of at 1%/minute. Accordingly, for example, based onone (or more determinations) that the battery of the device is beingcharged at a rate of 0.5%/minute concurrent with or otherwisechronologically proximate to a time with respect to which such a devicecan also be determined to be present/operating within a vehicle (such asa moving vehicle), it can be further determined, with respect to theconnection of such a device to a power source and charging of thebattery of the device at a rate of 0.5%/min, that suchcharacteristics/aspects indicate that it is relatively likely that thedevice is present/operating within a vehicle.

In certain implementations, one or more connectivity state(s) of thedevice can be used to determine whether or not the device ispresent/operating within a vehicle. For example, based on adetermination that the device is connected to a WiFi access point, theperformance of various power consuming operations (that might otherwisebe performed by/in relation the device, such as using the GPS of thedevice to determine whether the device is moving) can be avoided and/orlimited (such as by performing such operations less frequently).Moreover, the device can continue to operate in such a fashion (i.e.,avoiding/limiting the use of such operations) until the referenced WiFiconnection is terminated (and/or shortly thereafter). It can beappreciated that, in light of the fact that relatively few vehicles haveWiFi access points, an ongoing connection to a WiFi access point canindicate that the device is relatively unlikely to be in a vehicle.Moreover, in certain implementations, based on a determination that adevice is/is not connected to a Wifi AP, it can be determined that sucha device is not/is present within a vehicle (such as a moving vehicle).Moreover, in certain implementations, one or more operations can beinitiated, such as with respect to the device (e.g., employing,modifying, removing various restrictions that are employed with respectto the operation of the device).

Moreover, in certain implementations one or more of the technologiesdescribed herein can incorporate one or more machine learningtechniques, such as with respect to the WiFi access points that areperceptible to a particular device. In doing so, one or moredeterminations can be made, such as with respect to whether (a) anaccess point is static/stationary (e.g., within a home, office, etc.),as can be determined, for example, based on one or more perceptions ofsuch WiFi access points by the device concurrent with and/or inchronological proximity to one or more determinations that indicate thatthe device is unlikely to be moving, or (b) an access point isdynamic/mobile (e.g., within or on a car, train, bus, etc.) based on oneor more perceptions of such WiFi access points by the device concurrentwith and/or in chronological proximity to one or more determinationsthat indicate that the device is likely to be moving. The referenceddeterminations can be made, for example, by measuring the one or moreaspects of the motion(s) that can be perceived by/in relation to thedevice (based on one or more inputs that can originate, for example,from information/sources such as GPS, cellular IDs, cellular RSSI, WiFiIds, Wifi RSSI, accelerometer, gyroscope, etc.) concurrent with and/orin relatively close proximity to one or more determinations that thedevice is connected to (or is otherwise able to perceive or “hear”without necessarily being connected to) a WiFi access point (or throughthe use of a third-party database of Wifi access points, such asSkyhook, based upon which and/or in relation to which suchdeterminations can be made).

Moreover, the context within/in relation to which a device ispresent/operating (e.g., whether a trip, such as in a vehicle, hascommenced, whether the device is within a moving vehicle, whether thedevice is with a user walking, the vehicle class of a vehicle, etc.) canbe determined based on various determinations/identifications. Forexample, in certain implementations, based on (a) a determination that adevice is connected to a power source, and (b) a determination that oneor more wireless (WiFi), Bluetooth, cellular, etc., signals (such asthose originating from a WiFi access point) and/or one or more inputsoriginating at one or more sensors (e.g., accelerometer, gyroscope,magnetometer, proximity, pressure, light, camera, microphone, etc.), arechanging (e.g., changing above a certain threshold/degree of change)(e.g., different WiFi access point BSSIDs are determined to be cominginto/out of view, cell tower signal strengths are determined to bechanging more than a certain amount, etc.), it can be determined thatthe device is likely to be within a moving vehicle. Moreover, it can bedetermined that the device is relatively less likely to be in certaintypes of moving vehicles (e.g., bicycle, elevator) because devices arerelatively less likely to be connected to power in such situations. Inaddition, upon determining that a device is connected to a power source,one or more of the various determination techniques described herein(such as those pertaining to aspects of the power connectivity and/orpower consumption of a device) can be employed. In doing so, suchdeterminations with respect to the context of the device can be utilizedto conserve power (e.g., by deactivating, utilizing relatively lessfrequently and/or in a different way, and/or not utilizing at all, oneor more sensors, functions, and/or operations of the device, such asthose that consume power, based on the determined context of thedevice). Such functionality can be advantageous even when a device isconnected to a power source (e.g., an AC outlet) because a user may onlyhave a limited amount of time to charge his/her device and utilizingrelatively less power can enable the battery to charge more quickly.

Additionally, in certain implementations (including in scenarios where adevice may or may not be connected to power), based on (a) adetermination that one or more wireless (WiFi), Bluetooth, cellular,etc., signals (such as those originating from a WiFi access point) arechanging (e.g., changing above a certain threshold/degree of change)(e.g., different SSIDs are determined to be coming into/out of view,signal strengths are determined to be changing more than a certainamount, etc.), and (b) a determination that the device is not moving ina manner consistent with one or more activity types and/or vehicleclasses (e.g. the device is determined to be moving in a mannerconsistent with a user walking, a user bicycling, a user riding anelevator, etc.) and/or in the absence of a determination that the deviceis moving in a manner consistent with such one or more activity typesand/or vehicle classes (as can be determined, for example, in the caseof user walking, using various pedometric determination techniques, asare known to those of ordinary skill in the art, or in the case of auser in an elevator, for example, using a pressure sensor on the deviceto determine a relatively significant change in pressure over arelatively short time and/or distance), it can be determined that thedevice is likely to be present in conjunction with certain activitytypes and/or within certain vehicles classes types. In making suchdeterminations based on the referenced factors (e.g., changes pertainingto WiFi access points), a determination that a device is, for example,present within a moving vehicle, can be made even without the use of thedevice's GPS (which can otherwise entail considerable batterydischarge).

It should be noted that the utilization of techniques that enable thedetermination of the activity being performed and/or the vehicle classbeing used by eliminating (or otherwise determining a relatively lowlikelihood of) certain types of activities or vehicles (i.e., via a‘process of elimination’) can, in certain scenarios, enable relativelymore effective and/or efficient determination as to which activity isbeing performed and/or vehicle class is being used than afforded throughthe use of ‘positive’ or affirmative activity or vehicle classidentification/determination techniques. As in the above example, it canbe relatively easier/efficient, more accurate, require less power,and/or faster to determine that it is relatively likely that a device isin a moving vehicle by determining that the device is not present with auser walking, than by affirmatively determining that the device isrelatively likely to be present within a moving vehicle (e.g., based ona determination that its spectral frequency is within a certain range,etc., as described herein). For example, based on a determination adevice is connected to a power source, it can be further determined(even without having to use any additional battery power) that thedevice is relatively unlikely to be with a user who is walking orcycling. For example, determining that the device is not present with auser who is walking can be achieved by sampling an accelerometer and/orgyroscope for signs/indications/patterns of walking, which can be doneat a relatively lower sampling rate (thereby consuming less batterypower) than otherwise required to determine that the device is presentwithin a moving vehicle.

In certain implementations, based on a determination that a user/devicehas moved more than a certain distance (e.g., more than a distance thatcould otherwise be attributed to GPS ‘noise,’ even if not moving), suchas within a certain period of time, and further based on a determinationthat the device has not been operating in a manner that can bedetermined to be sufficiently consistent to walking (such as within thereferenced period), the user/device can be determined to be presentwithin a moving vehicle.

It should be noted that the various techniques described herein(including the referenced ‘negative’ or ‘reverse’ determinations thatare based on one or more determinations of context(s) that a device isnot present with respect to) can be employed in order to make any numberof determinations, including but not limited to: activitydetermination(s), vehicle movement determination(s), and/or vehicleclass determination(s). In doing so, such determinations can be achievedeven in scenarios/situations where determination-related ‘blind spots’might otherwise be present, such as in scenarios where GPS signals arenot available or otherwise reliable (e.g., in tunnels, undergroundgarages, cities with tall buildings, indoors, inclement weather, etc.).

It should also be noted that the various techniques described herein canalso enable the identification/determination of vehicles moving atpractically any speed (in contrast to otherwise waiting for the vehicleto reach a speed at which it can be determined that an unaided humancannot reasonably travel in order to affirmatively determine that adevice is present within a moving vehicle). In employing suchtechniques, it can be determined that a device is present within amoving vehicle even in a scenario where the vehicle is moving at arelatively slow speed.

Additionally, upon identifying/determining that a device is presentwithin a moving vehicle, it can be further determined that such a deviceis no longer present within a moving vehicle uponidentifying/determining that the device is present in conjunction with‘walking.’ (It should be noted that the terms Valking,“user walking,'etc., as used herein are intended to encompass any and/or all forms ofunaided human movement, such as walking, running skipping, etc.)

Accordingly, it can be appreciated that employing one or more of thereferenced techniques can enable determination(s) of one or moreactivities, operations, presence of a device within a moving vehicle,vehicle class(es), etc., without the use of GPS. In addition, in variousimplementations, the GPS of a device can, for example, be utilized onlywhen other signals are not sufficiently strong, clear, accurate, etc.,and/or to confirm the accuracy of such other determinations.

It should be further noted that, in certain implementations, one or moredeterminations can be made with respect to vehicle class based on theperception/identification of one or more RF devices (e.g., WiFi APs, BTdevices, etc.) that are in proximity of/present within the vehicle. Inorder to do so, for example, the identity (e.g., BSSID, SSID, MACaddress, etc.) of the RF device can be used to determine a likelihood ofa particular vehicle class (with respect to which the device ispresent). In doing so, it can be detected/determined that the device ispresent within a moving vehicle (such as in the manner describedherein). An identity of one or more related/comparable/similar RFdevices can be identified/determined, such as based on/in relation to adatabase that can maintain identities of various RF devices and theirrespective associated vehicle classes (as determined, for example, basedon inputs originating at one or more sensors of various devices, such asin the manner described herein). Moreover, one or more determinations(e.g., of a vehicle class) can be made based on similar, related, and/orcomparable (even if not identical) RF device identity information, suchas that stored/maintained in such a database. For example, in a scenariowhere a first BSSID of a WiFi AP is close/similar/comparable/related toanother BSSID of another WiFi AP that is identified/has been determinedto be in a public bus, the first BSSID can be determined to be likely tobe operating in relation to a bus, too (in light of the fact that buscorporations tend to purchase in bulk and are relatively likely toreceive successively/closely numbered devices). For example, if a datavalue of an RF device, like a WiFi AP's SSID, is an SSIDidentified/determined to be used in a public train (e.g.,“AmtrakConnect”), then it can be determined, with respect to another RFdevice having the same SSID or a similar/comparable SSID (e.g.,“AmtrakConnect2”) that such a device with the same/comparable SSID isalso on a public train. It should be noted that potential errors in suchdeterminations that may arise can be corrected by using one or moretechniques (such as those described herein) to validate the determinedvehicle class in relation to such RF devices. Additionally, the RFdevices operating in relation to vehicles in certain vehicles classes(e.g., buses, trains) are relatively likely to be perceived by multiplemobile devices simultaneously and over time than, for example, in a car.As such, one or more determinations as to the class of a vehicle can bemade based on the relative quantity of devices that perceive such an RFdevice simultaneously and/or over time. Thus, the greater the number ofdevices determined to simultaneously and/or over time perceive aparticular RF device, the relatively more likely it is that such devicesare present within certain types of “mass” vehicle classes (e.g., train,bus, etc.). Moreover, such RF device(s) can be associated with aparticular vehicle class on that basis, and/or using one or moretechniques such as those described herein.

The accuracy of such determinations can be further improved over time.For example, observing the same and/or similar changes with regard tocertain access points—such as during a trip—multiple times, can furtherconfirm that subsequent comparable observations can also be determinedto be occurring during a trip. It should also be noted that the accuracyof the referenced determinations can be further improved based on adetermination that the referenced signals (e.g., those originating fromWiFi access points, etc.) originate from a nomadic and/or non-nomadicsource, as determined, for example, using one or more of the techniquesdescribed/referenced herein. Moreover, in scenarios where the variouswireless, etc., signals are not available (or cannot otherwise be reliedupon), the GPS can be utilized, alone or in conjunction with othersignals and/or sensors), to determine whether the device is presentwithin a moving vehicle, etc. It should also be noted that one or moreadditional determinations can be made (e.g., upon determining that adevice is within a moving vehicle), such as with regard to the type ofvehicle that the device is in (e.g., car, boat, train, bus, etc.), suchas in the manner described herein.

In addition, in certain implementations one or more determinations canbe made with respect to the characterization and/or classification ofvarious WiFi access points (such as stationary/static/fixed/non-nomadicor mobile/dynamic/nomadic). Such determinations can be made, forexample, based on (a) information accumulated/stored by/in relation to adevice (such as overtime), (b) information accumulated by/in relation tomultiple devices (i.e., ‘crowd-sourced’) (such as overtime), (c) basedon information contained/identified within various WiFi broadcasts(reflecting, for example, the manufacturer, model, etc., of an accesspoint), as can be identified, for example, based on one or morecomparisons with one or more databases (as can be stored on the deviceand/or remotely) that contain data pertaining to which manufacturers,models, etc. are likely to be utilized instationary/static/fixed/non-nomadic or mobile/dynamic/nomadic contexts,and/or (d) in conjunction with third party services.

In another implementation, one or more of the contextual determinationsdescribed herein can be further configured to operate based on/inrelation to a premise/default/assumption that a device is notpresent/operating within a vehicle based on a determination that such adevice is connected to an access point that can be determined to benon-nomadic access point (i.e., an access point that can be determinedto have a relatively fixed location and/or whose location is notdetermined to change relatively regularly). Examples of such anon-nomadic/stationary access point can include a WiFi access point inan office network (in contrast to an in-vehicle WiFi access point or amobile device that can serve as a WiFi access point, a such devices canbe determined to be mobile).

It should be noted that, in certain implementations, the manner in whicha particular access point, such as a WiFi access point, can bedetermined to be non-nomadic/stationary can be achieved in a number ofways. For example, in certain implementations the nomadicity (that is,the nomadic/non-nomadic state/status) of an access point can bedetermined based on/in relation to a database (local or remote) that canmaintain information pertaining to various access points, and/or thatcontains respective classifications of such access points, such as inrelation to the nomadic/stationary and/or non-nomadic/mobilecharacteristics/properties of such access points (e.g., BSSIDs). Such adatabase can be built/compiled, for example, based on the results ofvarious nomadic/non-nomadic determinations that can be performed withrespect to various access points, such as is described herein (withrespect to individual devices and/or accumulated across devices, such asvia ‘crowd-sourcing,’ and/or utilizing a third party database of WiFiaccess points, such as Skyhook, that can provide the referencednomadic/non-nomadic information/determinations, or, based on adetermination that, by virtue of the method with respect to whichinformation pertaining to such WiFi access points wascollected/gathered, that the referenced WiFi access pointrecords/entries pertain to non-nomadic access points.

Moreover, in certain implementations the nomadicity of a an access pointcan be determined by querying/looking up the referenced access pointwithin a database (local or remote) that maintains associations of thecontext within which the device is present/operating with an identifierof the WiFi access point (e.g., a BSSID) that is the device is/wasconnected to. Such a database can be generated based on the results ofone or more determinations that pertain to the context within which adevice is present/operating in relation to the access point to which thedevice is connected, as described herein (both with respect toindividual devices and/or accumulated across devices, such as via‘crowd-sourcing,’ and/or may be a third party database of access pointsthat provides such information. For example, based on a determinationthat on multiple instances a device was connected to a particular WiFiaccess point and was also determined not to be present/operating withina vehicle, then upon subsequently determining that the device is againconnected to the same WiFi access point, it can be determined that thedevice is again relatively likely t not to be present/operating within avehicle.

Additionally, in certain implementations, one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to BSSID, Beacon, and/or WPS transmissions. For example,based on one or more of such items the identity of the manufacturer ofthe WiFi access point to which the device is connected can beidentified. By way of illustration, a BSSID of an access point can beused to identify the manufacturer. And, having identified themanufacturer, such an identity can be used to further increase theaccuracy of the referenced determination(s). For example, in a scenariowhere the BSSID of the WiFi access point to which a device is connectedis that of a manufacturer that makes mobile phones, it can be determinedthat there is a relatively greater likelihood that such an access pointis nomadic. Moreover, based on such a determination the context of sucha device can be further analyzed/checked (i.e., rather than solelyrelying on the connection of the device to the referenced access pointin order to determine the context of the device). For example, a WiFiaccess point having a BSSID prefix of 40:A6:D9 is assigned to WiFiaccess points made by Apple and can thus be determined to be relativelylikely to be an iPhone 4.

It should be noted that a database can also be utilized incases/scenarios where a manufacturer produces both nomadic andnon-nomadic devices, in light of the fact that such devices often havemultiple prefixes and different prefixes can pertain to differentdevices. Moreover, with respect to a given BSSID prefix, the value ofthe BSSID suffix (i.e., the last 6 characters of the 12-character BSSIDand which are generally assigned contiguously to similar/comparabledevices), can be compared to such a database in order to furtherdetermine the nomadicity of such an access point.

Moreover, in certain implementations additional information (e.g.,device type, model name, model number, etc.) pertaining to an accesspoint can be obtained, such as from WPS (WiFi Protected Set-Up)information of the access point, and such information can be used withrespect to determining the context and/or nomadicity of the accesspoint. For example, with respect to manufacturer the produces bothnomadic and non-nomadic WiFi access point under the same BSSID prefix,the model number of model name of the device (e.g. “Automotive WiFi HotSpot” or “Enterprise AP with 1 GB bandwidth”) can be used in order toidentify/determine whether the as access point is nomadic or non-nomadicand/or otherwise determine the context within which the device ispresent/operating.

Additionally, in certain implementations the nomadicity of an accesspoint can be determined based on whether the device can be determined tobe moving at the time it is also determined to be connected to theaccess point (such movement can be determined, for example, based on oneor more inputs/sources such as GPS, cellular IDs, cellular RSSI, WiFiIDs, Wifi RSSI, accelerometer, gyroscope, etc., such as are describedherein). In doing so, an access point can be characterized/classified asbeing nomadic based on a determination that the connected device wasmoving concurrent with and/or in relatively close chronologicalproximity to being connected to the referenced access point, while beingcharacterized/classified as non-nomadic based on a determination thatthe device was not moving concurrent with and/or in close chronologicalproximity to being connected to the referenced access point. Moreover,as described herein, the context of the device (e.g., being mobile orstationary while connected to the access point) can be recorded inrelation to the access point.

In other implementations, in addition to determining that a device isnot present/operating within a vehicle based on a determination that thedevice is connected to an access point determined to be non-nomadic, adevice can be positively/affirmatively determined to bepresent/operating within a vehicle based on a determination that thedevice is connected to an access point determined to be nomadic.

Moreover, with respect to access points having relatively higher powertransmissions (and therefore cover larger geographic ranges), it can beappreciated that the connection of a device to such access point(s) canbe relatively less indicative of the fact that the connected device isnot present/operating within a vehicle (as opposed to access pointshaving a relatively shorter transmission range). In suchcase(s)/scenario(s), one or more techniques (such as the RSSI technique)described herein can be utilized in order to make a determinationregarding the nomadicity of the access point.

In certain implementations, one or more of the access points that areperceptible to the device (e.g., other than an access point that thedevice is connected to), such as while scanning with the WiFi radio ofthe device, can be analyzed to determine the context of the device.Moreover, in certain implementations the access point to which thedevice is connected (if it is so connected) can be classified asnomadic/non-nomadic and saved (locally and/or remotely) for future use(such as by this device and/or with other devices), such as using one ormore techniques, such as those described herein. For example, in certainimplementations an access point perceived by a device can becharacterized/classified as nomadic/non-nomadic based on aquery/identification of a database containing a record of such an accesspoint (and/or a comparable access point based upon which suchdetermination can be made) and/or by making such determinationdynamically, such as based on information received/derived from theBSSIDs (e.g., manufacturer, model) and/or WPS information (e.g., model)of an access point. Thus, if a device can perceive one or more accesspoints that are known or have been determined to be non-nomadic accesspoints (such as over some period of time, in order to account fornomadic access points that may be perceptible to a moving device forrelatively short periods of time), such a device can be furtherdetermined to be stationary/not in motion. Moreover, if the device canperceive one or more access points determined to be nomadic (such asover some defined period of time), such a device can be determined to bein motion.

By way of further example, in certain implementations one or morecontexts associated with one or more of the access points that areperceptible to a device can be used to determine, with a certain degreeof likelihood, the current context of the device. For example, in ascenario where, upon perceiving a particular access point (such as anaccess point located in the vehicle of another user, such as when such auser parks in a company parking lot), it can be determined that thedevice is not present/operating within a vehicle, upon subsequentlyperceiving the same access point, it can be further determined that thedevice is, again, not present/operating within a vehicle.

By way of yet further example, in certain implementations one or moreother access points (e.g., those access points other than the one thatthe device is connected to) that are perceptible to the device can beanalyzed, such as across successive/intermittent scans of the WiFi radioof the device, such as even in scenarios where the nomadic/non-nomadiccharacterization/classification of such access points may not yet bedetermined. Based on a determination that one or more of (e.g., thecollection of) perceived access points across multiple/successive scansis substantially similar (and there are a relatively sufficient quantityof access points that are perceptible in such scans), then it can befurther determined that the device is not moving. However, based on adetermination that the collection of such perceived access points acrossmultiple/successive scans is relatively dissimilar, it can be determinedthat the device is moving. Moreover, the accuracy of determinationsachieved using such technique(s) can be increased/improved by analyzingthe RSSIs of the perceived access points in the collection (as opposedto looking at the presence or lack thereof of each access point acrossmultiple/successive scans. For example, in a scenario wheremultiple/successive scans are relatively close in time to one anotherand/or the device is moving relatively slowly, multiple/successive scansof perceptible access points using the WiFi radio of the device maydemonstrate a substantially similar collection of access points, but ifsome of the referenced RSSI values have changed substantially, it cannevertheless be determined that the device is likely in motion.

In certain implementations, the speed at which a device is moving can bedetermined/estimated based on a determination of the distance between(a) the location of the device at the time that the WiFi radio of thedevice is used to perform a first access point scan (e.g., as determinedfrom the known/determined locations of one or more of the BSSIDs, suchas from a 3^(rd) party database such as Skyhook, and further using errorminimization techniques to calculate the location of the device, such asbased on the respective locations of each of the access points that areperceptible to the device with or without using the RSSIs of such accesspoints as described herein, and (b) the location of the device at thetime that the WiFi radio of the device is used to perform another accesspoint scan, relative to the amount of time that elapsed between the twoscans. It should be noted that such a technique can be implemented withmore than two access point scans as well.

Moreover, in certain implementations the speed at which a device ismoving can still be determined/estimated even without locationinformation regarding (non-nomadic) WiFi access points. Suchdetermination(s) can be achieved, for example, based on changes in theRSSI of the WiFi access points across multiple/successive scans. Forexample, an access point whose RSSI on a device changes from −30 dB to−90 dB over the course of a relatively short period of time (e.g., 1second) can be determined to be relatively likely to bepresent/operating within a vehicle because, given the transmission rangeof WiFi access points, it is relatively unlikely that the device wouldbe capable of moving at such a rate of speed without being presentwithin a vehicle. However, with respect to an access point whose RSSI ona device changes from −30 dB to −31 dB over the course of a comparabletime period can be determined to be unlikely to be present within amoving vehicle because, given the transmission range of (most) WiFiaccess points, a moving vehicle is relatively likely to experience arelatively larger change in the strength of the signal received than 1dB, even over a relatively short period of time.

Moreover, in certain implementations, one or more techniques similar tothose described herein with respect to access points such as WiFi accesspoints can be employed with respect to determining a context withinwhich a device is present/operating based on the Bluetooth (BT)connectivity state/status of such a device. For example, based on adetermination that the device is connected to a nomadic BT device (e.g.,a hands-free car loudspeaker), it can be determined that the device ispresent/operating within a vehicle. Moreover, based on a determinationthat the device is connected to a non-nomadic BT device (e.g., a desktopcomputer), it can be determined that the device is not present/operatingwithin a vehicle. As described herein with respect to access points, aBT device (to which a device is connected) can becharacterized/classified as nomadic/non-nomadic in a number of ways. Forexample, in certain implementations the nomadicity of a BT device can bedetermined based on/in relation to a database (local or remote) that canmaintain information pertaining to various BT devices, and/or thatcontains respective classifications and/or characterizations of thenomadic/non-nomadic properties of various BT devices (BSSIDs). Suchdatabase can be built/compiled, for example, based on the results of oneor more of the nomadic/non-nomadic determinations described herein, bothwith respect to individual devices and/or accumulated across devices(‘crowd-sourcing’) and/or may be a third party database of BT devicesthat provides such nomadic/non-nomadic information.

Moreover, in certain implementations the nomadicity of a BT device canbe determined by querying/looking up the referenced BT device within adatabase (local or remote) that maintains associations of the contextwithin which the device is operating in relation to an identifier of theBT device (BSSIDs) that is the device was/is connected to. Such databasecan be generated/built based on the results of one or moredeterminations that pertain to the context within which a device ispresent/operating in relation to the BT device to which the device isconnected, as described herein (both with respect to individual devicesand/or accumulated across devices, e.g., via ‘crowd-sourcing,’ and/ormay be a third party database of BT devices that provides suchinformation. For example, based on a determination that on multipleinstances a device was connected to a particular BT device and it wasalso determined not to be present/operating within a vehicle, then uponsubsequently determining that the device is again connected to the sameBT device, it can be determined that the device is again relativelylikely not to be present/operating within a vehicle.

Additionally, in certain implementations, one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to BSSIDs. For example, the identity of the manufacturer ofthe BT device to which the device is connected can be identified, suchas is described herein. For example, the BSSID of a BT device can beused to identify its manufacturer. And, having identified themanufacturer, such an identity can be used to further increase theaccuracy of the referenced determination(s). For example, in a scenariowhere the BSSID of the BT device to which the device is connected isdetermined to be that of a manufacturer that produces hands-free carloudspeakers, it can be determined that there is a relatively greaterlikelihood that the BT device is nomadic, whereas based on adetermination that the BSSID of the BT device to which the device isconnected is that of a manufacturer that produces desktop computers, itcan be determined that there is a relatively greater likelihood that theBT device is non-nomadic.

It should be noted that a database can also be utilized incase(s)/scenario(s) where a manufacturer produces both nomadic andnon-nomadic devices, in light of the fact that such devices often havemultiple prefixes and different prefixes relate to different devices.Moreover, with respect to a given BSSID prefix, the value of the BSSIDsuffix (i.e., the last 6 characters of the 12-character BSSID and whichare generally assigned contiguously to similar/comparable devices), canbe compared to such a database in order to determine the nomadicity ofsuch a BT device.

Moreover, in certain implementations one or more of the referenceddeterminations can also incorporate and/or otherwise consider aspectspertaining to beacon transmission(s) pertaining to various BT devices,such as by querying/looking up the device class(es) (major and minor)and/or services class(es) of a particular BT device. For example, if adevice (e.g., a mobile device such as a smartphone) is connected to ahands-free BT device (having a BT major class of ‘Audio Video’ and a BTminor class of ‘Hands-Free’), it can be determined that the device (thatis, the mobile device) is relatively likely to be present/operatingwithin a vehicle. Based on such a determination, one or more powerconsuming operations (that may have otherwise be performed, such as inorder to determine the context of the device, e.g., using the GPS todetermine if the device is moving) need not be performed (or can beperformed relatively less often) until the BT connection is determinedto have been terminated (and/or relatively shortly thereafter).Alternatively, based on a determination that a device is connected viaBT to a desktop computer (having a BT major class of ‘Computer’ and a BTminor class of ‘Desktop’), the device can be determined to be relativelyunlikely to be present/operating within a vehicle. Based on such adetermination, one or more power consuming operations (that may haveotherwise be performed, such as in order to determine the context of thedevice, e.g., by using the GPS to determine if the device is moving)need not be performed (or can be performed relatively less often) untilthe BT connection is determined to have been terminated (and/orrelatively shortly thereafter).

Moreover, one or more of the referenced determinations can be made basedon a determination that a device was moving at the time it is connectedto the BT device (as determined, for example, based on GPS, Cell IDs,Cell RSSI, WiFi IDs, Wifi RSSI, accelerometer, gyroscope, etc., asdescribed herein), and a characterization/classification of the BTdevice to which the device is connected as nomadic based on adetermination that the device was moving while it was connected to theBT device (and non-nomadic if the device was determined not to be movingwhile it was connected to the BT device), and/or by recording orassociating the determined context of the device with the BT device.

In another implementation, the BT device(s) that are perceptible to adevice (such as a mobile device such as a smartphone) when scanning withits BT radio (other than the BT device that the device is connected to),can be used to determine the context of within which the device ispresent/operating (it should be understood that the referenced scans forBT devices can be made for discoverable and/or paired BT devices).Moreover, in certain implementations the BT device to which a device isconnected (if it is so connected) can be characterized/classified asnomadic/non-nomadic, and such characterization/classification can besaved (locally or remotely) for future use (such as by the referenceddevice and/or by other devices). It should be understood that suchdeterminations can be made in a number of ways. For example, in certainimplementations the nomadicity of a device (such as a mobile device suchas a smartphone) can be determined based on/in relation to thenomadic/non-nomadic characterization(s)/classification(s) of the BTdevices it perceives (such as by identifying records/informationcorresponding to such BT devices within a database) and/or making suchdeterminations dynamically based on one or more determinations withrespect to one or more combinations of information corresponding to themanufacturers, major and minor classes and services of such BT devices.In doing so, based on a determination that a device perceives, for arelatively/sufficiently long period of time (e.g., in order to filterout/account for non-nomadic devices that a moving device may perceivefor relatively short periods of time)one or more BT devices that havebeen determined to be nomadic, the referenced device can be determinedto be in motion, whereas if the device perceives, for asufficiently/relatively long period of time, one or more BT devices thathave been determined to be non-nomadic, the device can be determined notto be in motion.

Moreover, in certain implementations the nomadicity of a device can bedetermined based on/in relation to how one or more of the BT devicesthat are perceptible to the device has/have been previously associated,such as with a particular context. In doing so, one or moredeterminations can be made with respect to the present context of thedevice. For example, based on one or more instances with respect towhich a device perceives a particular BT device (e.g., the BT earpieceof another user) and also determines that the device is notpresent/operating within a vehicle, upon a subsequent perception by thedevice of the same BT device, it can be further determined that thedevice is (again) not present/operating within a vehicle (i.e., evenwithout making such a determination affirmatively).

Moreover, in certain implementations the nomadicity of a device can bedetermined based on/in relation to an analysis of the collection ofother BT devices (i.e., those BT Devices other than the one that thedevice is connected to) that the device perceives/“hears,” such asacross successive scans of its BT radio, even if the nomadic/non-nomadicclassification of such BT devices is not yet known. If the collection ofBT devices across successive scans is determined to be substantiallysimilar (and there are sufficiently many BT devices that are perceptiblein such scans), then the device can be determined not to be moving. If,however, the collection of BT devices across successive scans isdetermined to be substantially dissimilar, then the device can bedetermined to be moving.

The accuracy of such a technique can be increased/improved based on ananalysis of the RSSIs of the BT devices in the collection (e.g., ratherthan solely/primarily considering the Boolean existence/non-existence ofeach BT device in successive scans). For example, in a scenario wheremultiple/successive scans are sufficiently close in time and/or thedevice is moving relatively slowly, multiple/successive scans of BTdevices using the device's BT radio may be determined to demonstrate asubstantially similar collection of BT devices, however if some of theRSSI values can be determined to have changed substantially, the devicecan be determined to be likely to be in motion (i.e., relative to the BTdevices).

In another implementation, the speed at which the device is moving canbe determined/estimated by determining the distance between (a) thelocation of the device at the time that its BT radio is used to performa first BT device scan (e.g., as determined based on the known locationsof each of the (presumably non-nomadic) BSSIDs, such as from athird-party database, and using an error minimization technique tocalculate the location of the device based on the respective locationsof each of the BT devices perceived/“heard” with or without using theRSSIs of such devices, and (b) the location of the device at the timethat its BT radio is used to perform a second or subsequent BT devicescan, relative to the amount of time that elapsed between the two scans.It should be noted that this technique can be implemented with more thantwo BT device scans as well.

Moreover, even without location information regarding (non-nomadic) BTdevices, the speed at which the device is moving can still bedetermined/estimated, such as based on the changes identified in theRSSI of the BT devices in multiple/successive scans. For example, a BTDevice whose RSSI perceived on a device changes from −30 dB to −90 dBover the course of a short period of time (e.g., 100 milliseconds) canbe determined to be likely to be in a vehicle because, given thetransmission range of BT Devices, a human is generally un able to movethe distance required to change the signal so much in such a shortperiod of time, whereas a BT device whose RSSI on a device is determinedto have changed from −30 dB to −31 dB over the course of the same timeis relatively unlikely to be in a moving vehicle because, again, giventhe transmission range of (most) BT devices, a moving vehicle is likelyto experience a much larger change in the strength of the signalreceived than 1 dB, even over a short period of time.

It can be appreciated that most, if not virtually all cell towers arenon-nomadic. However, given that their transmission range is generallygreater than that of WiFi access points, the fact that a device isconnected to a cellular tower may provide relatively less specificcontext information than a device being connected to a WiFi accesspoint. Nonetheless, information regarding the cell tower to which adevice is connected can still be utilized to provide valuableinformation regarding the context of the device.

For example, if a device is determined to be connected to a cell towerthat has been previously associated with a particular context, it can bedetermined, with a certain degree of likelihood, that the device ispresent within such context again. For example, it can be determinedthat a particular device will tend to be connected to a certain celltower when the device is in the user's home and, generally, a differentcell tower when the device is in the user's place of work. Accordingly,if a device is connected to either of these cell towers its context canbe determined not to be within a vehicle and thus, if a device ispresently connected to either one of them, it can be determined that thedevice is not present within a vehicle. The accuracy of this techniquecan be improved/enhanced by ‘learning’ (such as via machine learningtechniques as are known to those of ordinary skill in the art) the RSSIsof cell towers for different contexts of the device (e.g., not within avehicle, within a vehicle, etc.), so that, for example, determinationssuch as (for example): if a device is determined to be connected to CellTower 12345 in LAC 123 at an RSSI of between −90 DB and −80 DB, thedevice can be determined to be likely not to be in a vehicle, can beachieved.

In another implementation, the cell towers that can be perceived/“heard”by the device when scanning with its cellular radio (other than the onethat the device is connected to) can be used to determine the context ofthe device. For example, based on a determination that a device canperceive/hear one or more cell towers that have been previouslyassociated with a particular context, it can be determined, with atleast a certain degree of likelihood, that the device is present in suchcontext again. For example, it can be determined that a particulardevice will tend to be connected to a certain cell tower when the deviceis present in the user's home and, generally, a different cell towerwhen the device is present in the user's place of work. Accordingly,based on a determination that a device is connected to either of thesecell towers, the context of the device can be determined not to bewithin a vehicle, and thus, based on a determination that a device ispresently connected to either one of them, it can be determined that thedevice is not present within a vehicle.

Moreover, in certain implementations a context of the device can bedetermined based on an analysis of the collection/set of other celltowers (i.e., those cell towers other than the one that the device isconnected to) that are perceptible to the device, such as acrossmultiple/successive scans of its cellular radio. Based on adetermination that the collection/set of cell towers that areperceptible to the device across multiple/successive scans issubstantially similar (and there are sufficiently many cell towers thatappear in such scans), then the device can be determined not to bemoving. If, however, the collection/set of cell towers that that areperceptible to the device across multiple/successive scans issubstantially dissimilar, the device can be determined to be moving.

The accuracy/resolution of such a technique can be improved/increased,for example, based on an analysis of the RSSIs of the cell towers in theset/collection (rather than only looking at the Booleanexistence/non-existence of each cell tower in multiple/successivescans). For example, based on a determination that the successive scansare sufficiently close in time and/or the device is moving slowly,successive scans of cell towers (such as using the device's cellularradio) may show a substantially similar collection of cell towers, butif some of the RSSI values have changed substantially the device can bedetermined to be likely to be in motion.

In another implementation, the speed at which the device is moving canbe determined/estimated by determining the distance between (a) thelocation of the device at the time that its cellular radio is used toperform a first cell tower scan (e.g., as determined from theknown/identified/determined locations of each of the cell tower IDs,such as from a third party database, e.g., Skyhook, and using an errorminimization technique to calculate the location of the device based onthe respective locations of each of the cell towers perceived with orwithout using the RSSIs of such cell towers), and (b) the location ofthe device at the time that its cellular radio is used to perform asecond cell tower scan, relative to the amount of time that elapsedbetween the two scans. It should be noted that such a technique can beimplemented with more than two cell tower scans as well.

Even without location information regarding cell towers, the speed atwhich the device is moving can still be determined/estimated, such asbased on the changes in the RSSI of the cell towers in successive scans.For example, a cell tower whose RSSI on a device changes from −30 dB to−90 dB over the course of a short period of time (e.g., 1 second) can bedetermined to be relatively likely to be present within a vehiclebecause, given the transmission range of cell towers, a human is notable to move the distance required to change the signal so much in sucha short period of time, whereas a cell tower whose RSSI on a devicechanges from −30 dB to −31 dB over the course of the same time isrelatively unlikely to be present within a moving vehicle because, giventhe transmission range of (most) cell towers, a device present within amoving vehicle is likely to perceive a relatively much larger change inthe strength of the signal received than 1 dB, even over a relativelyshort period of time.

It should be noted that accuracy of the referencedin-vehicle/not-in-vehicle determination(s) can be further improved whenperformed in conjunction with other connectivity/“network visibility”information/determinations (e.g., in relation to BT devices, cellularIDs, cellular RSSIs, etc.) and/or from other sensors as describedherein.

In another implementation, the conditions pursuant to which a device canbe determined to be present within a moving vehicle can be dynamicallydetermined, such as based on the device's environment, such as can bemeasured/determined by its sensors. For example, if many different WiFiaccess points (e.g., having different BSSIDs), many cell tower IDs(CIDs), and/or many Bluetooth devices are perceptible to a device,and/or if a GPS so indicates, it can be determined that the device isrelatively likely to be present in an urban area, whereas if relativelyfew (or none) of the referenced wireless signals are perceptible, and/orif a GPS reading so indicates, it can be determined that the device islikely to be in a rural area, and, because vehicles generally moveslower in urban areas than they do in rural areas, a threshold speed (orother conditions) at which a trip can be determined to have started (asdescribed herein) can be set/adjusted to be relatively lower in such anurban setting as compared to a rural setting, thereby enabling moreaccurately determinations in relation to contexts where/when devices arepresent within vehicles.

Not only can it be determined that, if a device is connected to anon-nomadic AP (e.g., for more than a relatively short time), it can bedetermined not to be moving, but further determinations can also beperformed. In doing so, for example, based on a determination that adevice is connected to a nomadic AP it can be further determined that itis relatively more likely the device is moving than if it were (a)connected to a non-nomadic AP, (b) connected to an AP of unknownnomadicity; and/or (c) not connected to an AP. In certainimplementations, such determinations can be premised based on anassumption/default that if a device is determined to be connected to anomadic AP, it can be determined to be is moving. Moreover, in certainimplementations, power/resources can be invested to determine, by way ofone or more other sensors (e.g., GPS, accelerometer, gyroscope, cellularradio, etc.) whether or not the device is moving.

Moreover, in certain implementations, a device determined not to be insubstantially the same location (e.g., as determined by GPS, WiFi APs,cell tower IDs, Bluetooth devices, IP address) (i) at or about the timeit connected to an AP as it is determined to be (ii) at or about thetime that the device disconnected from the same AP, can be determined tobe connected to a nomadic AP. Moreover, in certain implementations,irrespective of whether or not a device is determined to be atsubstantially the same location (i) at the time it connected to an AP asit was (ii) at the time that it disconnected from the same AP, thenomadicity of such an AP can be determined, for example, via GPS, suchas by comparing (i) the GPS coordinates of the referenced device'slocation at or about the time that the device connected to the WiFi APwith (ii) the GPS coordinates of the device's location at or about thetime of the device's disconnection from the same WiFi AP. By way offurther example, the nomadicity of such an AP can be determined, forexample via WiFi, such as by comparing (i) one or more of the WiFi APsperceptible at the device at or about the time of the device'sconnection to one of the WiFi APs with (ii) one or more of the WiFi APsperceptible at the device at or about the time of the device'sdisconnection from the same WiFi AP. By way of further example, thenomadicity of such an AP can be determined, for example via Cell TowerID, such as by comparing (i) the cell tower to which the device isconnected (or more or more of the visible cell towers) at or about thetime of the device's connection to the WiFi AP with (ii) the connectedcell tower (or one or more sets of the perceptible cell towers) at orabout the time of the device's disconnection from the same WiFi AP. Byway of further example, the nomadicity of such an AP can be determined,for example via Bluetooth, such as by comparing (i) one or more ofperceptible Bluetooth devices at or about the time of the device'sconnection to the WiFi AP with (ii) one or more of the visible Bluetoothdevices at or about the time of the device's disconnection from the sameWiFi AP. By way of further example, the nomadicity of such an AP can bedetermined, for example via IP address, such as by comparing (i) the IPaddress of the device shortly before the time of the device's connectionto the WiFi AP with (ii) the IP address of the device shortlyafter/about the time of the device's disconnection from the same WiFiAP.

In addition to, or instead of, the previously described technique(s)(which encompass techniques for determining nomadic WiFi APs), a WiFi APcan be determined to be non-nomadic based on a determination that thelocation of the connected device at the time it was connected to the APis substantially the same as its location at the time that itdisconnected from the same AP.

In addition, the longer (shorter) the period of time between theconnection and the disconnection (or the length of time that the deviceremains connected without disconnecting), such as in the abovereferenced scenarios, the greater the likelihood that the AP that thedevice was connected to was non-nomadic (nomadic). For example, a devicedetermined to be continuously connected to an AP for 10 hours can bedetermined, on average, to be relatively more likely to be connected toa non-nomadic AP than a device determined to be connected to an AP foronly 10 seconds.

It should be noted that the notion/concept/aspect of a ‘substantiallysame’ location (as referenced herein) can be determined, for example,relative to the transmission range of an AP. For example, it can beappreciated that certain APs can have a relatively wide transmissionrange (e.g., a WiMax AP), and in such a case it is possible that, eventhough the location at the time of connection and the location at thetime of disconnection may be determined to be relatively far apart, theAP is actually non-nomadic. As such, in one implementation, thetechniques described herein can be further configured to account for theAP's transmission range(s), as can be identified/determined, forexample, from/based on the BSSID, manufacturer, etc., of the AP, and/oras can be determined from repetitive crowd-sourcedconnection/disconnection locations, such as using one or more of thetechniques described herein. Using such techniques, WiFi APs can bedetermined to be nomadic or non-nomadic using “crowd-sourcing”techniques. For example, message(s) can be sent from user devices to aserver indicating (a) time, (b) conditions (pertaining to GPS, WiFi,cellular, Bluetooth, IP addresses, etc.) at or near the time ofconnection to the WiFi AP, and (c) conditions at or near the time ofdisconnection from the WiFi AP. It should be noted that, in certainimplementations, devices can also maintain and updatenomadic/non-nomadic AP information locally.

It should be noted that similar/related techniques can be employed inorder to determine whether other transmitters (e.g., Bluetooth devices,cellular stations, etc., and others currently existing or to beintroduced in the future) are nomadic or non-nomadic.

In certain implementations, the state of the device's display screen,keyboard and/or the presence of a device user (as determined, forexample, based on an absence/removal of a key-guard/lock on theinterface of the device, proximity sensed, etc.) can be used todetermine whether and/or how intensively (e.g., based on sampling rate,duty cycle, how much power can be consumed, etc.) device resourcesshould be used to determine the context of the device (e.g., todetermine if the device is present within a moving vehicle, determinethe in-vehicle role of its user, etc.), and/or to provide otherfunctionality, with or without taking into account the device's batterylevel, rate of battery level depletion, etc.

For example, if the device display screen is determined to be off(and/or applications with which the user can interact or receiveinformation from even when the device screen is off (e.g., an alreadyconnected call) can be determined not to be running or are restrictingthe application from providing such functionality), the powerconsumption of the device can be reduced (in light of the fact that thedevice, in its current state, cannot serve as a distraction to a driver)by reducing or eliminating some or all of its energy intensiveoperations (e.g., GPS calls) such as those used to make contextdeterminations (e.g., in-trip determinations, in-vehicle roledeterminations), as described herein. For example, upon determining thatthe screen is off, the GPS can be queried once every 5 seconds (or notat all), while when the screen is on, the GPS can be queried once persecond.

In one implementation, the device can be configured to maintain itselfin a low power consumption state in which much of, or substantially allof, the device's context information gathering can be suspended for aslong as the screen is off. Such techniques can be advantageous inscenarios where the context of the device can be promptly determinedwhen the screen is turned on (or a user is present). For example, onemanner in which this can be done is by turning the GPS on upondetermining that the screen is turned on. The latency associated withsuch a technique can be reduced by not turning the GPS radio fully offwhen the screen turns off, or by maintaining/“remembering” certaininformation that can that reduce the TTFF (time to first fix) of the GPSradio when it is next turned on, such as is known to those of ordinaryskill in the art.

By way of further example, successive scans of available/perceptiblenetworks/devices (WiFi, BT, Cell, etc.) can be performed (e.g.periodically) and the results maintained/recorded. Upon determining thatthe screen is turned on, the scan results just prior to and just afterthe device screen is turned on can be processed/used to determinewhether or not the device is in motion (and can also be processed/usedto determine/estimate the speed at which the device is moving).Moreover, the accuracy of the referenced technique can be improved bymonitoring (e.g., with a relatively low power consumption, such as at alow duty cycle) and thereby determining in advance which of the varioustechniques are likely to be useful/effective/accurate, in light of thedetermined context of the device. For example, the device cantest/determined, at various intervals while the screen is determined tobe off, whether the described Wifi scan technique is likely to beapplicable/accurate within the area in which the device is present(e.g., rural vs. urban). If it is determined that the referenced Wifiscan technique is not likely to be effective/available, it can bedetermined that another technique (e.g., one entailing higher energyexpenditure) may be required in order to accurately determine thecontext of the device (and can be employed, for example, when the screenis turned on), or it may choose to suspend the use of determinationsbased on screen state altogether, e.g., until WiFi scans can providerelevant/accurate information again.

In another implementation, a determination that a device is connected toa power source can further indicate the hands-free state and/orin-vehicle location of the device. For example, in a scenario where apassenger is present in a car, a device determined to be connected to apower source can be determined to (a) be relatively more likely to beoperated by a driver than by a passenger (because a vehicle is morelikely to have a power connection that is compatible with respect todevice operated by a driver than a device operated by a passenger, and(b) is relatively more likely to be positioned in close proximity to adriver than a passenger (in light of the near-driver location of somepower sources, e.g., a device cradle/dock having a power connection).

In another implementation, based on a determination that a device iscontinuously (or substantially continuously) connected to a power sourcesince before (or sufficiently soon after) it was last disconnected froma WiFi connection/AP (nomadic or non-nomadic), the device can bedetermined to be in the same location/context (e.g., within a vehicle,not within a vehicle, etc.) in which it was in when it was lastconnected to Wifi. In certain implementations, the accuracy of suchtechniques can be improved so that the device's current location and/orcontext can be determined based on the location and/or contextdetermined at the time that the last WiFi access point disconnected,based upon whether the WiFi access point is nomadic or non-nomadic. Forexample, in a scenario where the last WiFi access point to which thedevice was connected was determined to be a non-nomadic access point,the location of the device and its context (e.g., barring otherfactors/information) can be determined to be unchanged, whereas upondetermining that the last WiFi access point to which the device wasconnected was a nomadic access point, then, (barring otherfactors/information), its context (e.g., within vehicle) can bedetermined to be unchanged, while its location cannot. In certainimplementations, the accuracy of this technique can be further improvedby providing for/requiring that the device has be determined to becontinuously (or substantially continuously) connected to a power sourceat least a certain amount of time before it was last disconnected from aWiFi connection (in doing so, a use case where a user left his home andgot into his car in the driveway while still within range of her homeWiFi and connected the device to a power source in the car before losingconnection with the home Wifi can be addressed).

In another implementation, if a device is determined to be connected toa power source during the time that it has been determined to be in atrip, then, for as long as the device remains connected to such powersource (or an alternative power source, provided, for example, that thedevice is not unplugged from power for more than a certain period oftime, e.g., the time it might take someone to switch between a vehiclepower source and an office or home power source), it can be determinedthat the device is highly likely to still be within a trip. In sodetermining, many of the power expensive/intensive operations that mayotherwise be utilized by the device to determine the context of thedevice can be curtailed/suspended (e.g., checking GPS to see if thedevice is still present within a trip).

To the extent that the characteristics of the power source can bedetermined pursuant to the techniques described herein (or elsewhere),the determination as to whether the device is still connected to powerin a vehicle can be made relatively more easily/efficiently.

In addition, when a device is determined to be connected to power, andit is nonetheless determined that it should periodically re-detectwhether the device is in a trip or not, the efficiency of suchre-detection can also be improved (and can consume less power) becausedifferentiation between moving in a vehicle and certain other states(e.g., walking) which are highly unlikely when the device is connectedto power, may no longer be necessary.

In another implementation, upon determining that a device is presentwithin a trip and connected to a power source, it can be advantageous todetermine that a trip has ended so that, upon determining that a triphas ended, the device can be used by a user (i.e., without restriction)without having to disconnect the device from the power source (e.g., ina scenario where the vehicle is parked in a parking lot at the end of atrip with the device still being connected to power, and the user maywant to send a text). This can be achieved, for example, by sampling oneor more of a number of sensors and/or inputs (e.g., GPS, accelerometer,WiFi BSSIDs and/or RSSI, Cell Tower IDs and/or RSSI, BT BSSID and/orRSSIs) to determine if the device is in motion. In certainimplementations, such sensors/inputs can be sampled at sampling ratesrelatively lower than would be used if the power connection was notavailable and/or used to make contextual determinations (therebyreducing power consumption). Further, the sensors/inputs can also besampled at duty cycles relatively lower than those that would be used ifthe power connection was not available and/or used to make contextualdeterminations, thereby reducing power consumption.

It should be noted that the techniques described herein with respect toreducing power consumption are still applicable in scenarios in whichthe device is connected to a power source because, for example, if adevice battery is not near full and the time the device is presentwithin a vehicle is the only time a user has to charge the device, thenbeing able to give the battery the best charge possible (i.e., byreducing power consuming activities) can be advantageous.

Once the device is determined to no longer be connected to a powersource for a sufficiently long period of time, the techniques describedherein can be employed to determine if the device is still within a tripor not.

In additional implementations, the techniques described herein canaccount for whether the device is connected to a powers source, thedevice's current battery level and/or rate of battery level depletion,etc., in selecting which contextual determination techniques to useand/or how to use them (e.g., in relation to sampling rate, duty cycle,etc.). For example, upon determining that a device battery is fully ormostly charged, sensors can be sampled more liberally, whereas upondetermining that the device battery is low, sensors can be sampled on amore limited basis/more frugally. For example, when a device isdetermined to be connected to a power source, its GPS can be sampledmore frequently, whereas upon determining that the device is notconnected to a power source, its GPS can be sampled relatively lessfrequently (or not at all). Such techniques can also beemployed/extended to other sensor(s), e.g., accelerometer, WiFi scans,Cell tower scans etc.

In certain cases, it may be advantageous to use some combination of thetechniques described herein to improve the context determinationaccuracy and/or the associated power consumption.

Many of the context determinations described herein that employtechniques to use information in or related to network signals (e.g.,WiFi access points, BT Device and cell towers) can be improved withbetter/more accurate information as to the magnitude of the powertransmission of such signals. For example, for the power transmissionlevel at which a WiFi access point, a BT device or a cell tower emitteda signal can be used to determine/estimate speed more accurately. Basedon the fact that, for example, the RSSI of a BT device that transmits at2.5 mw (Class 2) has changed from −90 dB to −80 DB in 1 sec., it can bedetermined that the device is moving more slowly (relative to the BTdevice) than if the BT device transmits at 100 mw (Class 1).

In certain implementations, a device can allow simultaneous connectionto one or more networks of the same and/or different technologies. Thetechniques described herein can be adapted to such settings (e.g.,various voting techniques) using methods known to those skilled in theart.

In any/all of the techniques described herein, it may be advantageous toincorporate a “healing” mechanism whereby periodically checks can beperformed to determine/confirm that erroneous determinations have notbeen made (and/or that the device is operating in an incorrect state).For example, even when a device is connected to a power sourcecontinuously since a sufficiently long time before the last time it waslast disconnected to WiFi, the device can be periodically checked (e.g.,at a lower sampling rate/duty cycle than it might otherwise be checkedat) to further determine that it is not in a trip.

One or more of the techniques described herein can be implemented in anAPI that can be used by other applications running on/in relation to thedevice to provide such applications with accurate context information ina manner that is power efficient for the device. For example, anavigation application that wants to prevent a driver from thedistraction of inputting a destination while driving but wants to permita passenger to do so, can query such an API as to whether the device is(a) present within a trip and/or (b) is being operated by a driver or apassenger. By way of further example, using such an API, a navigationapplication (e.g., Waze) can be configured to turn itself on or offautomatically (with or without giving the user a chance to override),based on whether the device is determined to be within a trip or not(and the device can expend relatively little power to so determine). Inanother example, a telephony application (native or otherwise, e.g.,Viber, Skype, etc.) and/or a texting application (native or otherwise,e.g., WhatsApp) running on the device can determine whether or not toallow incoming and/or outgoing calls based upon the in-trip anddriver/passenger information/determination(s), as can be provided by thereferenced API.

In certain implementations, one or more aspects of thetechniques/technologies described herein can be configured in relationto a determination of a likelihood that a user associated with a deviceis going to be in a trip. It should be understood that such a likelihoodcan, for example be determined/estimated based on one or more inputs,factors, data elements, etc. (e.g., time, location, calendarinformation, user history, user or supervisor preference for tradeoffbetween latency, accuracy and power, etc.), such as those that maypertain to all users in a given population, pertain only to a segment ofsuch users (e.g., sex, demographic, location), and/or or pertain to aparticular individual user (e.g., calendar information, historical userbehavior, etc.). For example, based one or more determinations (such asthose corresponding to a particular context, as computed, for example,based on one or more on the referenced inputs, factors, data elements,etc.) relatively more resources (e.g., battery power, processing power,sensors, etc.) can be employed, activated, and/or otherwise dedicatedtowards one or more determinations pertaining to whether a user is/wasperforming a certain activity (e.g., present/traveling within a movingvehicle) during or near rush hour (as determined based on data pertinentto an entire population), during or near the time children aredriving/being driven/traveling to school within a certain neighborhood(as determined based on data pertinent to a particular populationsegment) and/or before a meeting scheduled within the user's calendar(as determined based on data pertinent to the individual user)—in orderto determine/identify such activity more accurately (by utilizing theadditional resources referenced above) and/or with less latency, withrespect to one or more of the referenced context(s). Moreover, acomparable configuration can also be employed to enable theusage/expenditure of relatively fewer resources in other context(s) todetermine whether the same user was performing such an activity at atime when (s)he can be determined to be relatively less likely to do so,e.g., in a moving vehicle in the middle of the night.

It should also be noted that, as noted above in detail with respect toFIG. 5, in certain arrangements, the processor 110 executing one or moreof software modules 130, including, preferably, determination module170, can transform an operation state of mobile device 105 based inwhole or in part on the one or more determination factor(s), such as theprobability computed at step 630. This operation can be furtherappreciated when employed in conjunction with a determination of anin-vehicle role of a user of mobile device 105, such as that depicted inFIGS. 2A-C and described in detail above. For example, in certainarrangements, upon determining (preferably to a certain minimumprobability) that a mobile device 105 is under the control of a driverof a vehicle (such as by processing the inputs from accelerometer 145Aand gyroscope 145B of mobile device 105 against those of other mobiledevices 160 within the same vehicle, thereby identifying the driver ofthe vehicle, as described in detail herein), it can then be furtherdetermined whether mobile device 105, which has been determined to beunder the control of a driver, is being operated in a handheld state(generally prohibited in most places) or in a non-handheld state(generally permitted). Accordingly, in such an arrangement (where mobiledevice 105 has been determined to be under the control of a driver andis being used in a handheld state), a transformation (substantiallysimilar to that described in detail above with respect to step 240) canbe employed In such a scenario, processor 110 can coordinate varioustransformations and/or adjustments to the operation(s) of mobile device105, as described in detail above with respect to step 240. As alsonoted above, in certain arrangements various of the referencedtransformations can be employed only when either one or both of theprobabilities pertaining to the user role of the user of mobile device105 is a driver and/or the handheld state of mobile device 105 ishandheld meet and/or exceed a certain minimum threshold.

Moreover, in certain implementations, a mobile device 105 that ispositioned in a cradle or dock (whether a ‘dumb’ cradle that simplyholds a device or a ‘smart’ cradle that provides power and/or otherconnectivity to a device) that has not already been authenticated to beoperated by a user that is a passenger (such as in the manner describedin detail herein) can be configured to employ a particular restrictionand/or set of restrictions (such as those described in detail herein)thereto, such restriction/set of restrictions preferably being differentthan restrictions that are employed at a device that has also not beenauthenticated as being operated by a passenger but is not in a cradle.Being that positioning a device in a cradle entails some degree ofadditional safety in relation to operation of the device on the part ofthe driver (being that the driver is not holding the device in his/herhand), in addition to the fact that in certain jurisdictions it ispermitted to operate mobile devices in certain manners when positionedin a cradle, it can be appreciated that in certain implementations, itcan be preferable to implement restrictions that account for thesefactors. For example, in such a scenario a cradled device can beemployed with a restriction that still allows the user to make and/or toreceive calls in geographic locations (e.g., a particular state orcountry) that allow the use of hands-free devices for calling, whereas acomparable non-cradled device can be restricted from even making suchcalls. It can be further appreciated that in certain implementations,such restriction(s) (and/or any of the other restrictions referencedherein) can be employed, for example, on/at the mobile device, on theSIM card, and/or by the cellular carrier (that is, in relation to themobile device).

In another implementation, the manner in which a device is beingheld/oriented (e.g., placed in a dock/cradle, hand-held, etc.) can bedetermined based on a spectral analysis of the frequenciesperceived/observed by the accelerometer and/or gyroscope of a device,such as in a manner known to those of ordinary skill in the art. Forexample, the spectral pattern perceived by the sensors of a handhelddevice (i.e., a device being held in the hand of a user) is likely to beidentifiably different from that perceived with respect to a device thatis placed in a dock/cradle, in that a handheld device will oftenperceive higher values (e.g., in a range of 3-7 hz).

In another implementation, the manner in which a device is beingheld/oriented (e.g., placed in a dock/cradle, hand-held, etc.) can bedetermined based on the orientation of the device (for example, as canbe measured based on inputs originating at the accelerometer,magnetometer, and/or GPS of the device, such as in the manner describedherein), in conjunction with a spectral analysis of theobserved/perceived frequencies (such as of the accelerometer and/orgyroscope), as described herein.

It should also be noted that the referenced processing/determining of anorientation of a device based on inputs originating from theaccelerometer of the device can encounter noise/interference when suchdeterminations occur within a running or ignited vehicle (i.e., avehicle having a running engine), as, for example, a running vehicle canimpart various forces that are perceptible to the device and/or thesensors of the device and which can cause anaccelerometer-measured/determined orientation to change, despite thefact that the actual orientation of the device may not change. Forexample, a device that is cradled /docked or otherwise held in an‘upright’ orientation will generally demonstrate no acceleration on itsX and Z axes, while demonstrating an acceleration of 1 g on its Y axis,and the angle of the device, as determined from the accelerometers ofthe device, is 90 degrees. Accordingly, in a scenario where the vehicleaccelerates at 1 g, and the device is oriented such that suchaccelerations are imparted on the Z-axis of the device, then theacceleration perceived on the Y and Z axes are each 1 g and the pitchangle of the device (as determined based on the trigonometricrelationship between the acceleration of its axis) is 45 degrees—whereasthe actual pitch angle of the device is 90 degrees.

Accordingly, in certain implementations, one or more inputs originatingat one or more sensors of a device can be used to filter out the noiseintroduced by vehicle acceleration events (as opposed to device-specificacceleration events). In doing so, the accuracy of the variousdeterminations with respect to the orientation of the device can beincreased/improved. For example, one or more accelerationevents/instances can be detected/identified, such as using one or moreother sensors, such as GPS, on-board car sensors, radio (e.g. Doppler,RSSI, cellular towers, WiFi, etc.), server-side techniques (e.g., OAO,TDOA), etc., which can be used to process the data originating from theaccelerometer and/or gyroscope of the device in an improved/moreaccurate manner. By way of illustration, In the referenced example, theGPS sensor of the device can measure/identify a change in speed of thevehicle that can be consistent with the referenced 1 g forwardacceleration, and it can be determined that the 1 g accelerationobserved with respect to the Z-axis of the accelerometer was present dueto the acceleration of the vehicle and not from a change in the actualorientation of the device, and, as such, it can be further determinedthat the actual pitch angle of the device remains 90 degrees (and not 45degrees).

It should also be appreciated that in certain implementations, one ormore restrictions can be employed at/in relation to a mobile device,based on a geographical determination, as referenced above. That is, inlight of differences in laws regulating mobile device usage by driversin difference jurisdictions, one or more restrictions can be selectivelyemployed at a mobile device based on a determination of the location ofthe device (e.g., based on inputs received from the GPS). Thus, in ascenario where State A prohibits texting while driving, while State Bprohibits texting while driving and talking while driving, theappropriate corresponding restriction (effectively preventing/precludingthe mobile device from performing the prohibited operation) can beemployed based on the location of the mobile device (as determined bythe GPS, cell towers and/or wifi transceivers seen/detected, as is knownto those of ordinary skill in the art).

In certain implementations, a device can be determined to be positionedin a cradle or dock based on the level of movement of the device. Forexample, a device that is held in a cradle will tend to move less than adevice that is not held fixed in a cradle—as can be determined based onan analysis of inputs originating at the accelerometer and/or gyroscopeof the device, and, for example, the tightness (e.g., standarddeviation) of the distribution of accelerometer readings or changesthereto, such as in a manner described herein and known to those ofordinary skill in the art.

In other implementations, the orientation of the device can be used todetermine if a device is in a cradle or not. For example, a device thatis in a cradle will have a fixed and known orientation (e.g., generallythe y-axis accelerometer, as shown in FIG. 9A) will pick-up a largecomponent of gravity and/or the X-axis accelerometer will pick up alarge component of gravity, as can be appreciated by those of ordinaryskill in the art.

In certain implementations, the presence/existence of connections to thedevice (smart' cradles supply power and/or connectivity to the device)can be used to determine if a device is in a cradle or not.

In yet other implementations, the orientation of a device relative tothe vehicle in which it is present can be used to determine if thedevice is in a cradle or not. If such orientation is fixed over sometime period, then it can be determined that the device is fixed (e.g.,is positioned in a cradle/dock). If such orientation is not fixed (e.g.,the device is actually hand-held), then it can be determined that thedevice is not in a cradle. For example, the orientation of the devicerelative to the vehicle can be determined at any point in time using (a)the device's GPS bearing, which measures the direction of movement ofthe device with respect to the Earth (denoted G), regardless of theorientation of the device within the vehicle; and (b) the device'smagnetometer/compass, which measures the orientation of the device withrespect to the Earth's magnetic field (denoted M), which depends on theorientation of the device in the vehicle and the bearing of the vehicle.For a device whose orientation with respect to the vehicle is fixed(e.g., a device in a cradle), a constant rotation matrix, R, can befound/computed, such that G*R=M, such as in a manner known to those ofordinary skill in the art. However, for a device whose orientation withrespect to the vehicle is not fixed (e.g., a hand-held device), suchrotation matrix is not constant.

It should also be understood that the identification of a device asbeing in a cradle/dock, as referred to herein, can beconfigured/expanded to any device whose position relative to thevehicle's is static and/or any device that is not hand-held.

Various of the referenced implementations and functionalities relatingto the cradle/dock status of the mobile device are described in greaterdetail below, specifically with respect to FIG. 24.

Turning now to FIG. 7, a flow diagram is described showing a routine 700that illustrates a broad aspect of a method restricting operation of amobile device 105 in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 700 share substantialsimilarities to those described above in connection with FIGS. 2A-C, 3,4, 5, and 6. It should be noted at the outset that while the followingdescription of routing 700 will be directed primarily to operationsoccurring at mobile device 105, such description is exemplary andintended for the sake of clarity and consistency. However, it should beunderstood that any and/or all of the steps in routine 700 can besimilarly employed at another device/machine, such as at central machine168, such as in the manner described in detail above with respect toFIG. 4. Furthermore, the same principle should be understood andappreciated with respect to any and all of the various steps,operations, and/or functions described throughout the presentdisclosure. That is, while any one of the particular steps, operations,and/or functions are described herein as being performed at and/or upona particular machine or device (such as mobile device 105, mobile device160, and/or central machine 168), such description should be understoodas being exemplary and/or illustrative and not limiting. Accordingly, itcan be appreciated that any and all steps, operations, and/or functionsdescribed herein with regard to a particular device and/or machine (suchas mobile device 105) should be similarly understood to be similarlycapably of employment at another device and/or machine (such as centralmachine 168), substantially in the manner described herein, withoutdeparting from the scope of the present disclosure.

At step 701, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whethermobile device 105 is present with a vehicle, such as through one or moreof the various determination methods described in detail herein.

Upon determining the mobile device 105 is within a vehicle (such as acar, a truck, a van, a motorcycle and a jeep.), at step 703, processor110 executing one or more of software modules 130, including,preferably, restriction module 171 determines whether the vehicle is inmotion, such as through one or more of the various determination methodsdescribed in detail herein.

At step 705 where processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, employs afirst restriction at mobile device 105 and/or in relation to mobiledevice 105. As will be described in greater detail herein, the firstrestriction is preferably one or more instructions that dictate at leastone operation state of the mobile device. Examples of such restrictionsinclude but are not limited to: instructions that disable a particularfeature or functionality of a mobile device 105 (such as the ability totype text), instructions that disable multiple features orfunctionalities of a mobile device 105 (such as the ability to launchcertain applications and the ability to receive text messages), andinstructions that functionally “lock” mobile device 105 by effectivelydisabling many or all of the functionalities of the device. It should beunderstood that in many arrangements, the referenced first restrictionis preferably a default restriction. That is, in such arrangements thefirst restriction is employed by default, such as upon powering onand/or activating mobile device 105. It should be appreciated that incertain arrangements such restriction can be employed in relation tomobile device 105, such as by a central machine 168, such as in themanner disclosed in detail herein, for example with respect to FIG. 4.By way of illustration, the referenced restriction can be imposed by acommunications provided (which preferably operates central machine 168)to prevent transmission of one or more communications (e.g., SMSmessages) to a mobile device 105, until an identification/determinationis made, such as identifying that two or more users are in a vehicle,such as in the manner disclosed in detail herein.

It should be understood that in various arrangements, including many ofthose described herein, the various restrictions employed at mobiledevice 105 are directed towards configuring mobile device 105 in such amanner that operation of and/or interaction with the device isdifficult, inconvenient, and/or impossible (that is, it can be said thatoperation of mobile device 105 is impeded) for a user who is alsosimultaneously operating a vehicle. At the same time, such restrictionsare also preferably configured to create minimal, if any, difficultyand/or inconvenience when operated by and/or interacted with by a userwho is not simultaneously operating a vehicle. In other words, it can besaid that such restrictions preferably impede operation of the mobiledevice by a user who is a driver moreso than they impede operation ofthe mobile device by a user who is a passenger. As such, it should befurther understood that in certain arrangements it can be preferably formobile device 105 to initially determine that the device is presentwithin a vehicle (such as through one or more of the variousdetermination methods described in detail herein) prior to employingsuch a first restriction. Accordingly, it can be further appreciatedthat the various steps and operations described herein with reference toFIGS. 7-8 can be further implemented, in certain arrangements, inconjunction with one or more of the various other methods and systemsdescribed in detail herein, such as those described with reference toFIGS. 2A-6. Furthermore, it should be recognized that any one or more ofthe various steps, operations, routines, functions, and/or figuresdisclosed herein can preferably employed in conjunction within any oneor more of the various steps, operations, routines, functions, and/orfigures disclosed herein. Thus, for example, the various restrictionsdescribed in conjunction with FIG. 7 can be employed in conjunction withthe various determination operations described above. By way of example,one or more of the referenced restrictions can be employed before theoccurrence of and/or in response to one or more of the determinationsdescribed in detail herein.

It should be understood that in various arrangements, at least one ofthe one or more restrictions that dictate the at least one operatingstate of mobile device 105 are determined based on inputs originating atat least one of the various sensors 145, etc., as described in greaterdetail herein.

At step 707, mobile device 105 preferably prompts one or more users toinitiate and/or provide one or more stimuli that can be received asinputs at mobile device 105. By way of example, mobile device 105 canprompt each of the one or more users in a vehicle to repeat a particularword or series of words projected by mobile device 105. It should beunderstood that in certain arrangements such a prompt can request forthe words to be repeated sequentially while in other arrangements such aprompt can request for the words to be repeated simultaneously, while inyet other arrangements the timing of the repetition is of noconsequence. It should be appreciated that such prompting can requestpractically any stimulus that can be received and/or analyzed as aninput in the manner described herein.

At step 710, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives at least afirst input and a second input (e.g., the referenced stimuli), in themanner disclosed in detail herein. As has already been described indetail herein, each of the first input and the second input preferablyoriginate at one or more of sensors 145, software modules 130, userinterface 172, operating system 176, and/or communication interface 150,though it should be understood that the first input and the second inputneed not originate from the same source.

It should be understood that, as referred to herein, such inputs arereferred to as originating at one or more of sensors 145, softwaremodules 130, user interface 172, operating system 176, and/orcommunication interface 150 in the sense that such inputs are initiallyperceived—from the perspective of mobile device 105—at such components.However, it should be recognized, as will be appreciated in connectionwith the following examples, that in many arrangements and scenariossuch inputs (and/or the stimuli and/or phenomena that trigger them) canultimately originate at sources other than at various components ofmobile device 105. Accordingly, it should be appreciated that within thecontext of the discussion of the subject matter encompassed by FIG. 7,various inputs are referred to as originating at a particular componentin the sense that they originate from such a component with respect tomobile device 105. However, it is acknowledge that such inputs can, inturn, have ultimate origins beyond mobile device 105 itself, such asfrom the voice of a particular user and/or from an external system ordevice, as illustrated below.

For example, a first input corresponding to the audio tones of the voiceof a first user can be received at microphone 145D, and a second inputcorresponding to the audio tones of the voice of a second user can alsobe received at microphone 145D. It should also be understood that incertain arrangements, one or more of the various inputs can be receivedat and/or originate from a source external to mobile device 105, such asvehicle data system 164 and or another mobile device 160. By way ofexample, vehicle data system 164 can provide an input to mobile device105 (preferably received via communication interface 150) indicating theweight measured on one or more seats of a vehicle, and/or the usage ofseat belts at one or more seats of a vehicle, etc—which can in turn,indicate that more than one user is within a vehicle. By way of furtherexample, a detection of mobile device 160 within a vehicle (using one ormore of the methods described herein) can also indicate that more thanone user is within a vehicle.

At this juncture, it should be noted that while the first input and thesecond input have been described herein as being discrete inputs, suchdescription is merely exemplary and for the sake of clarity andillustration. Accordingly, while in certain arrangements the first inputand the second input are separate inputs in the conventional sense—thatis, inputs that originate at two independent sources, in otherarrangements the first input and the second input are actually aspectsfound within a single input. For example, a single audio input (such asan audio recording) that contains two distinct voices (such as thevoices of a first user and a second user) can be processed (in themanner described herein) to identify such distinct voices within thesingle audio input, which are understood to be a first input and asecond input within the context of the present disclosure.

Then, at step 720, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, analyzes thefirst input and the second input. In doing so, the presence of at leastone of two or more users and/or two or more mobile devices can bedetermined, such as a determination of the presence of a first user andthe presence of a second user, such as in the manner described in detailherein. By way of illustration, continuing with the example referencedabove at step 710, the first and second inputs (that is, the audio tonesof the voices of the first user and the second user) can be analyzed toidentify an audio signature for each of the respective inputs, in amanner known to those of ordinary skill in the art, and such audiosignatures can then be compared to determine if they are substantiallysimilar and/or identical (indicating that both inputs likely originatefrom the same source, i.e., the same user) or substantially dissimilar(indicating that each of the inputs likely originate from differentusers). Thus, upon identifying that first input (here, the voice of thefirst user) is substantially distinct from the second input (here, thevoice of the second user), it can be concluded at minimum that thedevice 105 is in the presence of (if not in close proximity to) a firstuser and a second user. Additional illustrations of such inputs todetermine the presence of at least one of two or more users and/or twoor more mobile devices are presented below at EXAMPLE 4.

Upon determining that mobile device 105 is in the presence of at leastone of (a) two or more users and/or (b) two or more mobile devices, suchas by determining the presence of at least a first user and a seconduser, at step 742 processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171 modifies anemployment of at least one restriction such as the first restriction.That is, being that a determination (at step 720) that the device is inthe presence of at least two users necessarily indicates that at leastone of such users is not a driver of a vehicle, this conclusion canpreferably trigger and/or initiate the modification of the firstrestriction. In certain arrangements, such modification can include theemployment of a second restriction, strengthening of the firstrestriction, and/or the easing of the first restriction. In onearrangement, such a second restriction can include one or moreinstructions that dictate one or more operational states of the mobiledevice 105 with respect to one or more of the various sensors 145 of thedevice. That is, as noted above, such a restriction can configure mobiledevice 105 to operate in a manner that is relativelydifficult/inconvenient for a driver while being relatively unobtrusivefor a passenger. Put differently, it can be said that such restrictionsimpeded operation of mobile device 105 by a user who is a driver moresothan the same restrictions impede operation of a mobile device 105 by auser who is a passenger. Examples of such restrictions include but arenot limited to: requiring that the device only operate in ‘landscape’mode (which generally requires two hands for efficientinteraction/navigation—a demand that is relatively simple for apassenger to comply with but relatively difficult for a driver, whoneeds at least one hand to steer the vehicle, to comply with), requiringthat the device operate only at certain orientations (as detected by oneor more of sensors 145, such as gyroscope 145B, accelerometer 145A, GPS145C, and magnetometer 145E) such as a completely upright orientationwhich is relatively simple for a passenger to comply with but which isinconvenient for a driver who will not find such an orientation ascomfortable while driving and who will generally wish to hold the deviceat alternate orientations in order to obscure the device from the viewof law enforcement officials), and that the device not operate in amanner/pattern that is consistent with that of a driver (such as thevarious in-vehicle role determinations described in detail herein). Itshould be noted that although such restrictions are generally effective,on average, in impeding operation of a device by a driver moreso than apassenger, it is recognized that certain individual drivers may not findsuch restrictions particularly inconvenient, while other passengers mayfind them highly inconvenient. Nevertheless, on average, suchrestrictions impede the operation of mobile device 105 by drivers moresothat they impede such operation of mobile device by passengers.

In the event that the presence of at least one of (a) two or more usersand/or (b) two or more mobile devices, such as the presence of a firstuser and a second user, are not determined and/or one or more users notin the set of users known to be users of the mobile device, is notdetermined (at step 720), at step 744 processor 110 executing one ormore of software modules 130, including, preferably, restriction module171 maintains the employment of the first restriction.

In certain implementations, upon detecting/determining that a device ispresent/operating within a moving vehicle, one or more input methodsassociated with such a device (e.g., keyboard, voice commands, gestureinputs, etc.) can be modified or changed, such as to different inputmethod(s) that selectively restrict one or more aspects of thefunctionality the device. For example, based on adetection/determination that a device is present/operating within amoving vehicle, an on-screen keyboard can be replaced (or altered) suchthat the keyboard can only receive a single input/character during adefined time period (e.g., every 15 seconds). Alternatively, such inputmethod(s) can be selectively altered or replaced in relation toinstances during which one or more particular application(s), such asthose identified as being distracting (e.g., texting, e-mailing, webbrowsing, social networking, etc.), are executing at the device.

In another implementation, a determination can be made as to when thedevice is present/operating within a moving vehicle and, based on such adetermination, the device can initiate an operation mode that canselectively restrict one or more functionalities of the device (“DriverMode”), such as in the manner described herein.

FIG. 42 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4205 a perception of one or moresignals can be identified, such as in relation to a first device. Incertain implementations, the one or more signals can originate at one ormore other devices. At 4210, a performance of one or more authenticationtechniques can be enabled, such as in relation to the first device. Incertain implementations, a performance of one or more authenticationtechniques can be enabled based on an identification of the one or moresignals in relation to the first device.

When one device is in ‘Driver Mode,’ one or more other devices (such asthose executing a comparable application capable of selectivelyrestriction a device) can project or otherwise emit or provide a signalor notification (which, in various implementations, may be audible,inaudible, via Bluetooth, etc.) (referred to herein as a “SpecialSignal”). In certain implementations, such “Special Signals” can beconfigured such that they are perceptible only by other devices presentwithin the same vehicle (as can be achieved by providing such signals ata relatively law power of transmission, such that, in most cases, thesignals are unlikely to be perceptible to devices outside of thevehicle). Moreover, such signal(s) can be provided on a continuousand/or periodic basis (whether static, e.g., once every 15 seconds, ordynamic periodicity, e.g., at randomized intervals, at randomizedfrequencies, and/or in conjunction with randomized content generated bya remote server (such as in order to prevent tampering,).

Having initiated ‘Driver Mode’ with respect to a device (and/orotherwise restricted such a device) the referenced device can beconfigured (such as via the referenced ‘Driver Mode’) to enable anadjustment of such a state, such as changing/transitioning the device toanother operational state such as a passenger mode (“Passenger Mode”)based on a determination (and, in certain implementations, for as longas) that the device is capable of perceiving a ‘Special Signal’ emittedby driver device (e.g., a device determined to be operated by a driver,presumably originating from a device within the same vehicle).

In another implementation, a device operating in ‘Driver Mode’ can betransitioned to another state, such as to ‘Passenger Mode’ bysuccessfully performing one or more passenger authenticationtechnique(s), such as those described herein.

It can be appreciated that, in light of the fact that most vehicles haveonly one occupant in them, and such occupant is, by definition, thedriver, devices being operated by such solo drivers can be configured toinitiate ‘Driver Mode’ (and remain in such a state) because no ‘SpecialSignal’ is perceptible to such devices.

Moreover, in certain implementations, having initiated a ‘PassengerMode’ with respect to a device (such as in the manner described herein),such a device can be configured to cease to emit/project the referenced‘Special Signals.’

In certain implementations, information identifying the device that waspassenger authenticated (e.g., a device ID such as NEI), a SIM ID suchas IMSI, UUID, telephone number, etc.) and/or the device that enabledsuch authentication can be collected, time-stamped, GPS-stamped, savedand/or analyzed. In addition, information pertaining to when a passengerdevice ceased to receive a Special Signal and, therefore, left PassengerMode (e.g., corresponding to a trip stopping, the driver and passengerseparating, the driver turned off his/her device, etc.) can also bestored.

In another implementation, one or more aspects of the referencedinformation collected over time can be analyzed. In doing so, instancesin which one device is used to enable another device to operate in‘passenger mode,’ and the device that enabled such operation is thenobserved to operate in a relatively limited manner (e.g., with respectto calls, texts, data sent/received, contact present or changes thereto,applications run, etc.) outside of emitting a Special Signal, can beidentified. Identifying such instances can be advantageous in order toidentify drivers who may procure one or more additional devices to“sacrifice” as driver devices so that a second device can beauthenticated as a passenger device (such as in the manner describedherein) and used freely while driving.

In another implementation, a driver having a device that does not havethe software/application capable of configuring the device toproject/emit the referenced ‘Special Signal’ may have the option to (a)download or otherwise obtain a ‘lite’ version of the software thatenables projection/emitting of such a Special Signal (thereby enablingpassengers within the vehicle to transition their devices into PassengerMode, such as in the manner described herein), (b) go to a website thatplays a Special Signal, and/or (c) receive a Special Signal over a voiceconnection (e.g., by calling a phone number that plays a SpecialSignal).

Moreover, in certain implementations device users can stop the emissionof a Special Signal from their devices. In so doing, a passenger canprevent a driver from using his/her device in Passenger Mode (orattempting to).

In public transportation settings/scenarios, the referenced SpecialSignal can be emitted by and/or amplified by hardware within thevehicle. Alternatively, other devices that perceive a Special Signal canalso relay (or “repeat”) such Special Signal, thereby increasing itseffective range of transmission.

In another implementation, a passenger device can be prompted to requestfor a driver device to emit a Special Signal, rather than have alldevices within a vehicle emitting a Special Signal until they transitioninto Passenger Mode.

Turning now to FIG. 8, a flow diagram is described showing a routine 800that illustrates a broad aspect of a method restricting operation of amobile device 105 in accordance with at least one embodiment disclosedherein. As will be described in greater detail below, various of thesteps and operations that make up routine 800 share substantialsimilarities to those described in detail herein.

At step 801, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whethermobile device 105 is present with a vehicle, such as through one or moreof the various determination methods described in detail herein.

Upon determining that mobile device 105 is within a vehicle (such as acar, a truck, a van, a motorcycle and a jeep.), at step 803, processor110 executing one or more of software modules 130, including,preferably, restriction module 171 determines whether the vehicle is inmotion, such as through one or more of the various determination methodsdescribed in detail herein.

At step 805, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step705. It should be understood that such restriction(s) are preferablyconfigured to impede operation of mobile device 105 by a user that is adriver moreso than the restriction(s) impede operation of mobile device105 by a user that is a passenger, as described in detail herein.Examples of scenarios where the operations of routine 800 can beimplemented include teenage drivers (wherein a parent/guardian wishes toemploy such restrictions, which make it difficult to operate a mobiledevice 105 while driver, at all times) and/or phones that are fixed invehicles, such as car phones (wherein it is always desirable toimplement such restrictions). It should be appreciated that in certainarrangements such restriction can be employed in relation to mobiledevice 105, such as by a central machine 168, such as in the mannerdisclosed in detail herein, for example with respect to FIG. 4. By wayof illustration, the referenced restriction can be imposed by acommunications provided (which preferably operates central machine 168)to prevent transmission of one or more communications (e.g., SMSmessages) to a mobile device 105, until an identification/determinationis made, such as identifying that two or more users are in a vehicle,such as in the manner disclosed in detail herein.

It should be further understood that in certain arrangements, suchrestriction can be further configured to impede operation of the mobiledevice, and/or be more likely to be applied to a mobile device used by adriver than to a mobile device used by a passenger. By way of example,consider a scenario where a particular restriction is employed such thatif the ‘shake’ perceived at mobile device 105 exceeds a certainthreshold level, SMS messages cannot be sent from the device. It can beappreciated that employment of such a restriction does not impededrivers more than passengers (being that, once employed, it will impedea driver and a passenger equally), however such a restriction is morelikely, on average, to be employed for drivers than for passengers(being that drivers, on average, shake their devices more thanpassengers). Further such examples are provided at EXAMPLE 4.

It should be further understood that, as described in detail above, suchrestriction(s) can be configured to be applied to a mobile device asused by a first user moreso than such restrictions are applied to amobile device used by a second user. By way of example, suchrestrictions can be configured to impede a user who uses the mobiledevice in an unauthorized operation state moreso than a user who usesthe mobile device in an authorized operation state. By way ofillustration, one such example, which is preferably directed topreventing students from using their mobile devices while they are in aclassroom setting, can impose a restriction such that the mobile deviceis only operable and/or functional if the device is held upright and/orat a certain altitude (as can be determined based on one or more ofsensors 145, as described in detail herein). In doing so, students willeffectively have to hold their mobile devices upright and in a certainconspicuous orientation, such that it will be very difficult for suchstudents to operate their mobile devices inconspicuously during a class,such as underneath a desk. Accordingly, it can be appreciated that sucha restriction impedes users (here, students) who use their mobiledevices in an unauthorized operation state (that is, for example, duringclass), which such a restriction does not impede users who use theirmobile devices in an authorized operation state (that is, when not inclass) to the same degree. It should be further understood that thereferenced examples and illustrations are merely exemplary, and thatmany other such restrictions within the scope of the present disclosureare similarly possible.

Additionally, a device that is located in a vehicle can be used todetermine whether the vehicle's engine is on or off. One manner in whichthis is useful, is when considering that a vehicle that has recentlystopped moving, but whose engine is still on, may likely continue itspresent trip (e.g., stopped at a red light), whereas a vehicle that hasrecently stopped moving and whose engine is off has likely finished itspresent trip. Differentiating between these two states in useful, amongother reasons, in order to know when usage restrictions on a driver'sdevice should be lifted, such as in the manner described herein.

In one implementation, the device's accelerometer and/or gyroscopeand/or magnetometer can be used to determine whether the engine isrunning or not. For example, the accelerometer and/or gyroscope and/ormagnetometer show larger movements and/or movement at differentfrequencies, when the engine is running as opposed to not running.

In another implementation, the device's microphone(s) is used todetermine whether the engine is running or not. For example, themicrophones will show signals at different frequencies, includingharmonics of the base frequency which can be more easily detected by themicrophones used on popular devices, when the engine is running than ifthe engine is not running.

In yet another implementation, the event of starting or stopping theignition can be captured by the accelerometer, gyroscope and/ormicrophone. For example, the magnitude of the acceleration at the timethe ignition is started or stopped is considerably larger than theprevious and subsequent accelerations in a stationary vehicle.

In yet another implementation that may be particularly useful forelectric vehicles, the event of starting or stopping the ignition may becaptured by the magnetometer because the magnetic field created by anelectric car will change when the car is turned on or off.

It can be appreciated that in certain situations it may be useful (a) torestrict driver devices in vehicles that are temporarily stopped, forexample at a stop light (i.e., not moving, but that have been movingrecently and whose engines are still on and/or whose ignition hasn'tbeen turned off); but (b) to not restrict device's in vehicles that werejust turned on, for example, still in their parking spot (i.e., notmoving, and were not moving recently, but whose engines has been startedrecently).

Additionally, it can be useful to measure the accelerometer readingand/or magnetometer readings across the 3-axes using anorientation-invariant, for example, using the RMS of the accelerationson each of the 3 axes or other techniques known to those of ordinaryskill in the art of signal processing and time-series analysis.

Additionally, it should be appreciated that various time parameters canbe associated with many of the above methods so as to effectivelydifferentiate between events or states that are recent and ones that arenot.

Turning now to FIG. 12, a flow diagram is described showing a routine1200 that illustrates a broad aspect of a method for restrictingoperation of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1200share substantial similarities to those described in detail herein.

At step 1201, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 determines whether afirst mobile device 105 is present within a vehicle, and/or receives oneor more first inputs from at least one of a vehicle data system 164and/or at least one of a second mobile device 160, the one or more firstinputs pertaining to a presence of the first mobile device 105 within avehicle, such as through one or more of the various determinationmethods described in detail herein.

Then, at step 1207, mobile device 105 preferably prompts one or moreusers to initiate and/or provide one or more stimuli that can bereceived as inputs at mobile device 105 and/or receives one or moresecond inputs in response to the prompting, and/or receives one or morethird inputs from vehicle data system 164, and/or receives one or morefourth inputs from at least one of the second mobile device 160, all inthe manner described in detail herein.

At step 1220, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, analyzes at leastone of the first inputs, the second inputs, the third inputs, and thefourth inputs to determine a presence of at least one of more than oneuser, more than one mobile device 105, 160, and/or one or more users notin the set of users known to be users of the first mobile device,substantially in the manner described in detail herein.

At step 1242, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 employs one or morerestrictions at a mobile device 105, substantially in the mannerdescribed in detail herein.

Turning now to FIG. 13, a flow diagram is described showing a routine1300 that illustrates a broad aspect of a method for restrictingoperation of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1300share substantial similarities to those described in detail herein.

At step 1305, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105, substantially in the manner describedabove with respect to step 705.

In certain implementations, such a restriction can be employed wherebythe device can prompt/require the user is to authenticate that s/he is apassenger in a vehicle (such as a moving vehicle) by performing anaction or a set of actions such as a CAPTCHA, a game, a puzzle, lockscreen etc., as described in detail herein. It can be appreciated thatsuch authentication can be configured to require sufficientconcentration/attention such that the authentication can be difficult toperform by a driver of a moving vehicle, who must concentrate ondriving. This authentication can be further strengthened by requiringthat (a) in order to complete the action the user must use both hands(for example, by requiring multitouch input, as described in detailherein and illustrated with respect to FIG. 15A), and/or (b) configuringthe restriction to require the user to tilt his/her head and/or eyesdown or up or right or left (for example, by requiring that the devicebe held flat, placed in the user's lap or on the seat between the user'slegs, in the manners described herein) thereby preventing the user frombeing able to see the road ahead while performing the authentication,and/or by requiring that the user look directly in to the device, asdescribed in detail herein.

At step 1310, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, preferably from at least one of the mobile device 105, a vehicledata system 164, and/or one or more other mobile devices 160,substantially in the manner described above with respect to step 710. Byway of further illustration, in certain implementations, such inputscorrespond to one or more inputs provided by the user to the device inresponse to an authentication prompt (it should be understood that theterm “authentication prompt” as used herein is intended to encompass oneor more prompts, instructions, and/or directions that inform a user insome manner as to the manner in which inputs should be provided to adevice, and/or that otherwise provide information to the user relatingto the authentication of such a device).

At step 1320, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, analyzes at leastone of the inputs. It should be understood that in certainimplementations, such analysis can be performed in order to determine apresence of one or more users that are not known users of the firstmobile device 105, substantially in the manner described in detailherein. In other implementations, such analysis can be performed inorder to determine whether and/or to what degree one or more inputs(such as those received at step 1310) successfully and/or unsuccessfullyauthenticated a mobile device 105, as is also described in detailherein.

At step 1342, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, modifies anemployment of one or more restrictions at a mobile device 105,substantially in the manner described in detail herein.

Turning now to FIG. 14, a flow diagram is described showing a routine1400 that illustrates a broad aspect of a method for orienting acoordinate system of a mobile device 105 in accordance with at least oneembodiment disclosed herein. As will be described in greater detailbelow, various of the steps and operations that make up routine 1400 canshare substantial similarities to those described in detail herein. Itshould be understood that the various steps of routine 1400 will beappreciated with reference to EXAMPLE 3 below and FIGS. 9-11B, and theiraccompanying descriptions.

At step 1410, processor 110 executing one or more of software modules130, including, preferably, determination module 170 receives one ormore inputs, preferably from at least one of (i) at least one of theuser interface, the operating system, the accelerometer, the gyroscope,the GPS receiver, the microphone, the magnetometer, the camera, thelight sensor, the temperature sensor, the altitude sensor, the pressuresensor, the proximity sensor, the NFC device, the compass, and thecommunications interface of the mobile device 105 and (ii) a vehicledata system 164, substantially in the manner described in detail herein.

At step 1430, processor 110 executing one or more of software modules130, including, preferably, determination module 170 computes, based onthe one or more inputs, an orientation of the mobile device 105 relativeto a coordinate system of a vehicle, such as a vehicle within whichmobile device 105 is traveling.

At step 1440 based on the orientation, processor 110 executing one ormore of software modules 130, including, preferably, determinationmodule 170 interprets one or more subsequent inputs of the mobile device105 in relation to the coordinate system of the vehicle and/ortransforms the one or more subsequent inputs originating at the firstdevice into values that are comparable with the coordinate system of thevehicle. See, for example, FIGS. 11A-B and EXAMPLE 3, below.

It should be understood that mobile device 105 is preferablycommunicatively coordinated with the vehicle data system, that vehicledata system is preferably configured (e.g., installed) with the vehicle(e.g., within the vehicle such as a car) and/or that mobile device ispositioned within the vehicle, as described in detail herein.

By way of illustration, consider that based on the x, y and zaccelerometers, the exact orientation of the device 105 can bedetermined relative to the ground (e.g, based on the gravitational forceshown on the three accelerometers 145A, as is known to those of skill inthe art based on such disciplines as trigonometry). When the device iswithin a moving car with additional forces, the inputs can be averagedover time and/or inputs from the gyroscope 145B can further assist thiscomputation.

The orientation of the mobile device 105 can be detected relative to thecar, for example, by using the angle between the device's magnetic north(e.g, from the 3-axis compass sensor) and the vehicle's GPS heading (ascan be shown on the mobile device).

Accordingly, it can be appreciated that in the case of a moving carthere are also additional forces (other than gravity). These forces canbe accounted for, for example, through averaging over time and/or byusing the mobile device's gyroscope 145B, as described herein and usingmethods known to those of ordinary skill in the art.

In the case that there are movements at the mobile device 105 that areunrelated to the car (say the user moved the device), these can beaccounted for through time averaging and/or using the gyroscope 145B andor filtering out these higher frequency events, as described herein andusing methods known to those of ordinary skill in the art.

By way of further illustration, consider that in a mobile device on aflat table, the Z-accelerometer shows gravity and the X-accelerometerand Y-accelerometer show 0.

If the mobile device is rolled or pitched (so that one side or onecorner of the device remains in contact with the table), the value readby the z-accelerometer goes down (some of the gravity that it felt instage one is handed over to the other accelerometers)and theX-accelerometer (for roll) and Y-accelerometer (for pitch) go up. Thetotal sum of squares of the 3-accelerometers is always gravity. So weknow the exact orientation of the device with regard to the ground.

To orient/align the device 105 with the coordinates of a car, thedevice's 105 north (detected, e.g., via its compass sensor) can becompared with the vehicle's GPS (such as from vehicle data system 164)heading (as read on the device). For example, (if the device screen isfacing up, i.e., the device is not upside down) and its compass sensorshows that magnetic north is due north and the GPS heading sensor showsthe vehicle is travelling due west, then the device is rotated 90degrees to the right with regard to the car. Accordingly, the exactorientation of the device with respect to the coordinates of the car, asdisclosed herein and described in greater detail at EXAMPLE 3 and withregard to FIGS. 9-11B.

By way of further illustration, in the case of a 2.5 g lateralacceleration detected at the mobile device 105, that could be becausethe mobile device 105 was in a very tight turn (right or left) orbecause there was very strong forward acceleration or deceleration—orsome combination thereof. We cannot know what the car did (if anything)to cause this 2.5 g acceleration until we understand the orientation ofthe device 105 within the car and can transform the 2.5 g lateralacceleration felt on the phone into the acceleration in the vehicle'scoordinate system, which is achieved through implementation of routine1400.

It should be noted that, for the purpose of the simplicity of thedescription and without any loss of generality, in one or more of theexamples below, it will be assumed that the various mobile device(s)105, 160 is (are) aligned with the vehicle within which they aretraveling, such as as shown in FIG. 11A. That is, the coordinate systemof a particular mobile device 105, 160 should be understood to becoincident with the vehicle's coordinate system, as depicted in FIG. 11Aand described in greater detail in EXAMPLE 3. It should be furtherrecognized that in practice, such as in various arrangements, such asthat shown in FIG. 11B, mobile device 105, 160 is rotated with respectto the coordinate system of the vehicle in up to three dimensions. Inorder to correctly analyze the various inputs originating at sensors 145of mobile device 145 within the context of the coordinate system of thevehicle, the rotation of the particular mobile device 105, 160 relativeto the vehicle is preferably computed and the inputs originating atsensors 145 of the particular mobile device 105, 160 are preferablytransformed into values for the coordinate system of the vehicle. Thismay be achieved in various ways, examples of which are provided below.

It should also be noted the several of the examples provided herein arepresented from an event-centric perspective for the purpose of clarity.That is, various of the inputs originating at sensors 145 of mobiledevice 105, 160 have been described as corresponding to variousreal-world events such as turns, bumps, and/or stops. Accordingly, itshould be appreciated that such event-centric descriptions are providedherein for the purposes of illustration and clarity, and are notintended in any way to be understood as limiting the scope of thepresent disclosure. Additionally, is should be appreciated that thevarious determinations described herein can also be performed from asensor-centric perspective, wherein the various inputs originating atsensors 145 are considered, irrespective of a particular real-worldevent to which they correspond. It should be understood that the variousapproaches described herein can be employed in both even-centric andsensor-centric perspectives.

It should be understood that the following examples encompass furtherarrangements and embodiments of the systems and methods disclosedherein.

EXAMPLE 1

There are a number of inputs that can be utilized in variousarrangements in order to identify one or more user determinationcharacteristics, such as the location of a mobile device 105 and/or if amobile device 105 is being operated by the driver or by the passenger ofa car/truck/bus, such as:

As also noted above, various arrangements preferably incorporateidentification of one or more of the user determination characteristicsreferenced above and herein. In certain arrangements, each userdetermination characteristic (e.g. error proportion, correlation oftyping speed to acceleration etc.) can be considered as a point in aK-dimensional space. Classification algorithms based on supervisedlearning, as are well known to those of ordinary skill in the art, canthen be applied to the resulting K-dimensional signature(s) to determinethe probability that the in-vehicle role of the user of mobile device105 is a driver or a passenger.

Text Reading/Screen Viewing—User determination characteristic(s) can beidentified based on patterns in the reading of text messages (or anyother such text item such as an email or webpage, or any other suchviewing of items on a display screen, such as during the playing of avideo game) on a mobile device 105, thereby serving to distinguishbetween a driver and a passenger. For example, drivers tend to changethe orientation of and/or move (e.g. rotate in his/her palm) mobiledevice 105 more frequently when attempting to read a message of a givenlength (in order to periodically glance back at the road), whereas apassenger will read such a message in a comparatively more constantstate. This is especially true during road maneuvers that require moredriver concentration, such as turns and accelerations. This phenomenoncan be observed as a high degree of correlation between vehicleaccelerations and/or gyroscopic rotations as detected by accelerometer145A and gyroscope 145B, respectively, of mobile device 105 and thechanges in orientation of the mobile device 160 (unrelated to movementsin the vehicle) as measured by one or more of accelerometer 145A,gyroscope 145B, GPS 145C and magnetometer 145E and, in particular, thepresence or absence of a (non-vehicle related) mobile device movementsjust prior to vehicle movements. Preferably, once this correlationreaches or exceeds a certain threshold, the in-vehicle role of the userof mobile device 105 can be determined to be a driver and/or once thiscorrelation reaches or exceeds another certain threshold, the in-vehiclerole of the user of mobile device 105 can be determined to be apassenger.

Driver-Specific Movements—Various movements and/or forces can bedetected by one or more of sensors 145 of mobile device 105 that can bedetermined to be unique to a driver. In the alternative, a lack ofperception of such unique forces, such as “signature” forces at a mobiledevice 105 can indicate that the user of such a device is not a driverand is thus a passenger. When in contact with a device 105 (such as whenholding it), a driver influences the movement of a mobile device 105through driver-related actions that include pressing and releasing thegas/brake/clutch pedals and by moving his/her foot from one pedal toanother over the course of driving. For example, prior to a period ofstrong and prolonged acceleration perceived by accelerometer 145A ofmobile device 105 (which is typically due to acceleration, braking,and/or wheel rotation), there is a smaller, different accelerationand/or angular movement perceived slightly (in the 100's ofmilliseconds) in advance, such as at one or more of sensors 145, thatoriginates at the driver's body maneuver (such as the pressing of a gaspedal) that initiates the acceleration of the vehicle. A driver alsocauses a mobile device 105 to move by rotating the steering wheel. Thus,in a case where a mobile device 105 is in contact with a driver turninga steering wheel, various of sensors 145, such as accelerometers 145Aand/or gyroscope 145B of mobile device 105 can detect certainaccelerations and rotations. Based on a retrospective analysis of suchinputs—for instance, analyzing inputs corresponding to acceleration of acar with inputs perceived immediately prior—it can be determined whetherthe user operating such a mobile device 105 is a driver or a passenger.If such unique/signature forces are perceived in close proximity(generally, immediately before) acceleration, etc., it can be determinedthat the user is a driver. Conversely, if such inputs are not detectedimmediately prior to acceleration, it can be determined that the user isa passenger (provided that the user is in physical contact orcommunication with mobile device 105).

By way of further illustration, prior to a period of strong andprolonged lateral acceleration and/or gyroscopic yaw perceived byaccelerometer 145A and gyroscope 145B of mobile device 105 due toturning, there is a smaller, different acceleration and/or angularmovement perceived slightly (in the 100's of milliseconds) in advancethat originates at the driver's body maneuver that initiates the turningof the steering wheel and that is unlikely to be that of a passenger.

This approach can be also applied to other driver movements (e.g.,looking in the mirrors, turning on the directional signal), wherein thedriver's movements will be detected on mobile device 105 that is incontact with the driver slightly before another signal is detected(e.g., accelerometer 145A or gyroscope 145B for looking in mirrors,microphone 145D for turning on directional), on mobile device 105,whereas these serial relationships will not be present if mobile device105 is being operated by a passenger.

In certain implementations, a device determined to be located within avehicle can process various inputs, such as in order tocharacterize/determine the nature of a particular movement of thevehicle. For example, various inputs can be processed in order todifferentiate between a vehicle that has recently stopped moving and islikely to continue its present trip (e.g., stopped at a red light orstopped in traffic) from a vehicle that has recently stopped moving andis relatively likely to have finished its present trip. In doing so, itcan be determined when usage/operational restrictions (such as thosedescribed herein) employed with respect to a device determined to beoperated by a driver of a vehicle should be lifted or otherwisemodified/eased (e.g., upon determining that the vehicle is relativelylikely to have finished its present trip, as opposed to only coming to atemporary stop), such as in the manner described herein.

FIG. 35 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3505 one or more inputs can bereceived, such as in relation to a user device. At 3510, at least one ofthe one or more inputs can be processed. In certain implementations, atleast one of the one or more inputs can be processed in order todetermine one or more mobility characteristics of the device. Moreover,in certain implementations one of the one or more inputs can beprocessed based on a determination of a mobility stoppage, such as inrelation to the user device. In certain implementations, one or moreinputs that are chronologically proximate to the mobility stoppage canbe processed, such as in order to determine one or more mobilitycharacteristics of the device. Moreover, in certain implementations theone or more mobility characteristics can include at least one of (a) apermanent stop or (b) a temporary stop. Moreover, in certainimplementations, at least one of the one or more inputs can be processedin relation to one or more data items, such as in order to determine oneor more mobility characteristics of the device. In certainimplementations, the one or more data items can include at least one of:map data, traffic signal data, or traffic condition data. At 3515, oneor more restrictions can be selectively adjusted, such as in relation tothe user device. In certain implementations, one or more restrictionscan be selectively adjusted based on the one or more mobilitycharacteristics.

FIG. 36 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3605 an indication of a completion of atrip can be received, such as in relation to a user device. At 3610, oneor more inputs can be processed, such as in order to determine one ormore mobility characteristics of the user device. In certainimplementations, such one or more inputs can be processed based on theindication. At 3615, the one or more mobility characteristics can beprocessed, such as in order to determine a veracity of the indication.In certain implementations, the one or more mobility characteristics canbe processed in relation to the indication. At 3620, one or morerestrictions can be selectively adjusted, such as in relation to theuser device. In certain implementations, one or more restrictions can beselectively adjusted based on the veracity. In certain implementations,one or more restrictions can be maintained, irrespective of a subsequentindication of a completion of a trip.

In one implementation, one or more inputs that correspond to thebehavior or operation of a vehicle prior to its stop, such as thoseoriginating at the accelerometer, GPS, magnetometer, and/or gyroscope ofthe device can be processed, for example, in order to determine whetherthe vehicle traveled in reverse one or more times just before it stopped(indicating parallel parking), and/or whether the vehicle performed aturn in the period of time just preceding its stop (indicating entryinto a parking lot or a driveway).

In another implementation, the frequency and/or length of stops (asdetermined based on a processing of one or more of the inputs referencedherein) made in the time prior to the current stop can be used todifferentiate between these two states (i.e., between a temporary and apermanent stop). A vehicle determined to have made stops (of variouslengths) in the recent past and/or in close proximity to the location ofthe current stop and/or is on a travel route determined to be consistentwith the previous stops, can be determined to be relatively more likelyto be stuck in traffic than a vehicle that has not.

In another implementation one or more inputs originating at a device'slocation sensitive sensor/radio (e.g., the GPS of the device) can beprocessed to determine (a) whether the vehicle is near a traffic light,(b) whether the acceleration/deceleration of the vehicle (i.e., stoppingand going) correlates with the changes in the traffic lights (e.g.,their green—yellow—red pattern) on the route that the vehicle isdetermined to be traveling, and/or (c) whether the vehicle is on a roadthat currently has heavy traffic that could be the cause of the stopsobserved, as can be aided by data originating at one or more trafficdensity services (e.g., Waze, DeCell, etc.).

It should also be noted that the methods contained above may consist ofthe device also using information from vehicle data system 164 (e.g.,OBDII), e.g., the speed of the vehicle and/or the gear in which thevehicle is engaged.

It can be appreciated that, in certain scenarios, one or more‘trade-off(s)’ or compromise(s) may need to be made with respect to howto process determinations pertaining to temporary stops/slow-downs inmovement in order to determine when a device is in a moving vehicle andthereby selectively restricting functionality of the device on thatbasis (i.e., should the trip be determined to be over, in which case theselective restriction should be removed, or is the vehicle stopped, suchas at a red light, in which case perhaps the selective restrictionsshould not be lifted). It can be further appreciated that implementing a‘timeout’ period (e.g., determining that a trip is over after adetermination that a device has not moved for X minutes) can entailcertain shortcomings. For example, drivers who have ended their trip andwant to use their devices prior to the end of X minutes will befrustrated with such a restriction and drivers who are still withintheir trip, and who are stopped/moving slowly for more than X minutes(e.g., heavy traffic, long light) may nevertheless be able to use theirdevices which is dangerous/illegal.

Accordingly, in certain implementations an “honor system” can beemployed, whereby drivers can self-declare their trips to have ended byproviding/inputting such a declaration/indication to the device (e.g.,via touch, voice, visual (e.g., gesture), shake etc. input), based uponwhich one or more restrictions can be modified, eased, or otherwiseremoved from the device without having to wait until a determination ismade that the device is static/slow for a certain period of time.

If, however, a determination that the device is present within a trip ismade within a certain period of time after the referencedself-declaration of a trip end is received, the user of such as deviceand/or the device itself can be given/ascribed a “strike.” Uponaccumulating more than a certain number of strikes, the referencedself-declaration mechanism/technique can be disabled or otherwise ceaseto work (or will be made to work less effectively), such as with respectto the particular user and/or the particular device. Moreover, incertain implementations the referenced “strikes” may subsequently becanceled or otherwise “evaporate” based on to different events (e.g.,the passage of a certain amount of time, such as each strike expiringone week after it is created, the travelling of a certain distance—eachstrike expires 10 driving hours after it was created), etc.

In another implementation, a driver who has completed a trip canself-declare a trip to be over (such as in the manner described above),and such a self-declaration can cause an immediate (or shortlythereafter) determination to be triggered by acquiring sensorinformation and/or other information to determine, as soon as possible,whether or not the trip has ended (i.e., sooner than would otherwise bedetermined using various other techniques). Such a feature can beadvantageous, for example, in settings where, in an attempt to savepower, the various data acquired to determine whether or not a trip hasended are acquired with latency (e.g., with delay, in duty cycles)and/or at less than the fastest sampling rates possible. Accordingly, byacquiring one or more of the referenced data items relatively morequickly (such as upon receiving an indication, such as from a user, thatthe trip has concluded) one or more of the determinations that can bemade in order to lift/remove the referenced selective restriction(s) canbe initiated relatively faster/sooner. Stated differently, suchtechnique(s) can enable ongoing power-saving techniques to be appliedmore readily while reducing the degradation to the user experience.

In another implementation, a similar technique can be used to allow auser to cause the device to immediately (or relatively more quickly thatit would ordinarily have) re-check or re-query whether or not it is in atrip. Such a technique can be advantageous, for example, in situationsin which the device was determined to be present within a trip when, inactuality, it was not (false positive) and/or in situations in which thedevice was determined not to be present within a trip when, inactuality, it was (false negatives).

Moreover, upon determining that a device is present within a trip, itcan be advantageous to apply different (or asymmetric) methods todetermine whether or not the trip has ended, such as based upon whetherthe device is being operated by a driver or a passenger. For example,the trip detection techniques (such as those described herein) employedwith respect to devices determined to be operated by passengers can beeased relative to devices determined to be operated by drivers. Forexample, power can be saved by lowering the rate at which one or moresensors (e.g. GPS, accelerometer, cellular, Wifi, BT radios, etc.) on adevice determined to be operated by a passenger are sampled in order todetermine whether a trip has ended. It can be appreciated that adding alatency aspect to the detection of a trip end is not generally painfulto passengers who have so authenticated because their devices do nothave selective restrictions employed (or are relatively less restrictedthan devices determined to be operated by drivers).

In another approach, the mobile device of a driver will, on average,display larger movements than that of a passenger measurable by sensors145 of mobile device 105 due to the fact that the driver is likely to beholding the mobile device 105 in only one hand, whereas a passenger ismore likely to be using both hands to hold a mobile device 105, or iscapable of increased focus even when using only one hand to operatemobile device 105. This can preferably be done by taking the Fouriertransform of a 3D acceleration function and integrating it (squared,i.e. L2-norms) over N disjoint frequency intervals, as is well known tothose of ordinary skill in the art. The resulting 3N numbers arepreferably a “signature”. The signature corresponding to a driver can bedistinguished from that of a passenger using a classification algorithm,such as SVM, which has preferably been trained on sufficiently largepre-classified signature bank, as is also known to those of ordinaryskill in the art.

GPS—GPS 145C of mobile device 105 can be used, preferably, in certainarrangements, in conjunction with other sensors, to identify thein-vehicle position of mobile device 105. In certain arrangements thisis achieved in part based on knowledge of the lane boundaries of theroad on which the vehicle is driving (based on map data orcomputation/observation), together with a determination of mobiledevice's 105 location, using GPS 145C, to be on the right or left sideof such lane. If mobile device 105 is in the left part of its currentlane, then it can be determined to be on the left side of the vehiclewithin which it is traveling, while if it is in the right part of itscurrent lane, then it is on the right side of the vehicle. Such in-lanelocation calculations can further be averaged over time to increase theaccuracy of the location of the mobile device 105 within its thencurrent lane and, as a result, the accuracy of the determination of thelocation of mobile device 105 inside the vehicle.

It should be understood that the term “turn” as used herein can refer toa turn or any angle and/or curvature and/or any change in lateralacceleration and/or gyroscopic yaw, no matter how large or small and thecomparisons described above can be applied discretely or continuously.It should also be appreciated that such inputs can be perceived atpractically any time and/or interval, even those that do not necessarilycorrespond to “turns” as conventionally understood, and such inputsshould be understood to be within the meaning of the term “turns” asused herein.

It should be understood that the term “bump” as used herein can refer toa change of any size in the upward acceleration, irrespective ofpositive or negative change and irrespective of how large or small andthe comparisons and filtering described above can be applied discretelyor continuously at regular or irregular sampling rates.

Magnetic Field—A vehicle's metallic and electrical parts influence themagnetic field in the vicinity of and inside such vehicle. A 3-axismagnetometer 145E of mobile device 105 can be used to detect theseinfluences by measuring such magnetic field(s) at various times beforeand during a vehicle's operation (e.g., a car that has not yet beenstarted will have a different magnetic signature than one in which theelectric systems are operating) and by comparing them with knownmagnetic signatures of different in-vehicle locations in order todetermine the in-vehicle location of mobile device 105. Such signaturescan be universal and/or can depend on additional parameters such asvehicle model, vehicle location, etc.

For example, the major metallic component in most vehicles is the motorand in most vehicles (e.g., cars, buses), and it is normally situated inthe front part of the vehicle, near the center. The magnetic fieldsensed by magnetometer 145E of mobile device 105 can be compared withthe magnetic field that is otherwise present absent the magneticdisturbances—thereby indicating the direction of the motor. The lateralcomponent of that direction is preferably the opposite of the left-rightin-car location of mobile device 105.

User Baseline vs. Population Baseline—As described in detail above, suchas with respect to step 224, in the identification of many of the userdetermination characteristics described above, the values and signaturesmeasured on and/or computed with and/or in relation to mobile device 105are compared to baseline values (which are preferably stored in one ormore databases 174, 162) in order to determine if mobile device 105 isthat of a driver or a passenger. In certain arrangements, such baselinevalues can be independent of the user (e.g., the standard deviation ofthe time between keystrokes for all people in the country using aparticular model phone), while in other arrangements such values can beuser dependent (e.g., this mobile device 105 (or this user of thismobile device 105, if such is available) usually texts at 100 charactersper minute, currently he is texting at the rate of 10 characters perminute—thus the person holding it is likely driving).

EXAMPLE 2

As noted above, such as at steps 222 and 223, considering multipleinputs can increase the accuracy of one or more of the determinationsdescribed herein, such as the determination of an in-vehicle role of auser of a mobile device 105, 160. This advantage is further illustratedabove at steps 225 and 226, wherein inputs from multiple devices areconsidered in order to compute such determinations. Furtherillustrations of such inputs/determinations include, but are not limitedto:

In-Vehicle Location—In the United States and in most other countries inthe world, drivers are the left-front most occupant in a vehicle,relative to the front end of the vehicle. By identifying whether aparticular mobile device 105, 160 is or is not the left-front mostdevice within a vehicle, a determination can be made that such device105, 160 is or is not being operated by the driver.

It should be understood that the referenced in-vehicleidentification/determination is preferably achieved in conjunction withcommunication between mobile device 105 and one or more of mobiledevices 160, whether through direct communication or through network166. It should also be appreciated that in certain arrangements suchidentification(s)/determination(s) can be performed in a server-sideconfiguration, while in other arrangements suchidentification(s)/determination(s) can be performed in a client-sideconfiguration. In one such server-side configuration, one or moresoftware modules 130 are preferably executing at the various mobiledevices 105, 160. One or more of the modules configure the each of therespective devices 105, 160 to transmit its absolute locationcoordinates (such as those provided by GPS 145C and/or an inertialnavigation system (INS) and/or its relative location (e.g., 3 metersfrom WiFi device #1234) to central machine 168. Central machine 168 canthen process the various locations coordinates and/or relative locationsreceived from the various devices 105, 160 in order to determine whichof the various devices 105, 160 are sufficiently close to one another,over a period of time (e.g., 1 minute, 1 hour, etc.), based on which itcan be determined that such devices 105, 160 are present within the samevehicle. In a client-side configuration, the mobile devices 105, 160communicate between one another (such as through communication interface150), exchanging absolute location and/or relative location anddetermining which other devices 105, 160 are in within the same vehicle,substantially in the manner described above with regard to theserver-side configuration. By way of further example, in certainarrangements one of devices 105, 160 can emit a tone and/or signal (suchas an audio tone), and only those devices 105, 160 that perceive theemitted tone are determined to be within close proximity of the devicethat emitted the tone.

In both server-side and client-side configurations, upon determiningwhich mobile devices 105, 160 are within a particular vehicle, sensordata (that is, data originating at one or more of sensors 145, such aslocation coordinates from GPS 145C, or lateral accelerations during aturn) from the various devices 105, 160 can be compared with one anotherto determine a relative in-vehicle location of one or more of thedevices 105, 160. Such relative location can be subsequently filtered togenerate a real-time driver-passenger determination, providingincreasing accuracy in driver/passenger identification.

Driver-Anticipatory Movements—The driver of a vehicle is generallybetter able to anticipate the movements of the vehicle he/she is drivingas compared to the passengers because the driver is the initiator ofmany of the movements that the vehicle undergoes, and can thusanticipate the forces that are created as a result of the vehicle'smovement. Such predictive actions can be detected by one or more ofsensors 145 of mobile devices 105, 160 (e.g., accelerometer 145A and/orgyroscope 145B), and can be further processed to identify whether aparticular mobile device 105, 160 is being used by a driver or apassenger. A driver instinctively tenses and/or flexes certain ofhis/her muscles to adjust for the vehicle movements that are about tooccur on average, more adroitly (less sudden with less corrective bodymovement) and more quickly than a passenger does. By way ofillustration, a driver anticipates and compensates for the forcesexperienced during a turn quicker and more accurately than a passengerin the vehicle does. Similarly, a driver anticipates and compensates forthe forces experienced during sharp deceleration (braking) more quicklyand more accurately than a passenger. A driver also anticipates andcompensates for the forces of a lane change more quickly and moreaccurately than a passenger. By way of further illustration, the drivercan be thought of as a dampening system which performs better than acorresponding “passenger” system, due to the driver's higher degree ofconsciousness, awareness, and/or anticipation. In one arrangement, oneor more of the listed effects/phenomena can be detected/identified byprocessing one or more inputs from one or more sensors 145, such as bymeasuring the change in acceleration (i.e. the L2 norm of the derivativeof the acceleration) over the relevant time window. In this case theacceleration is preferably further band-pass filtered to focus only onfrequencies relevant to this determination, and to further exclude otherdriver-acceleration effects (e.g., hand-shaking, etc.) as discussedherein.

Magnetic Field: A vehicle's metallic and electrical parts influence themagnetic field in the vicinity of and inside such vehicle. Inputsoriginating at a 3-axis magnetometer 145E of a mobile device 105, 160can be used to detect and determine these influences by processing suchinputs to determine a magnetic field at various times before and duringsuch vehicle's operation (e.g., a car that has not yet been started willhave a different magnetic signature than one in which the electricsystems are operating) and by comparing them with known magneticsignatures of different in-vehicle locations in order to determine thein-vehicle location of such device 105, 160. The presence of two or moredevices within a single vehicle can influence each other's magneticreadings in a way that can be determined based on their comparison. Itshould be understood that in certain arrangements, such signatures areuniversal while in other arrangements they depend on additionalparameters such as vehicle model, vehicle location, etc. In addition,comparing the magnetometer 145E inputs from more than one mobile device105, 160 located within the same vehicle can enable a more accuratedetermination of the in-vehicle location of one or more of such devices.

EXAMPLE 3

As noted above, the processing of the various inputs discussed herein ispreferably enhanced by incorporating various additional processingoperations which serve to further enhance the accuracy of thedeterminations that are made. Examples of such further processingoperations include, but are not limited to:

Clock synchronization—As noted above, in arrangements where inputsoriginating from multiple devices 105, 160 are processed together (suchas several of those referenced above in EXAMPLE 2), it is preferablethat simultaneous timing measurements originating at the respectivedevices 105, 160 are compared as well. In one arrangement, this can beeffectively achieved by synchronizing the internal clocks of therespective devices 105, 160. By way of illustration, a relativedisplacement can be estimated, and this estimate can be used to processall relevant inputs such that they are synchronized to the same clock.

Examples of such synchronization methods include: (A) processing timeinputs from GPS 145C to compute a mean time displacement between GPSclock and each the clock of each device 105, 160. The difference betweenthose displacements can be determined to be the displacement between thedevices. (B) Configuring one of the devices 105, 160 to emit a sound andreceiving the sound at a second device (such as at microphone 145D), andfurther noting the time the respective events occurred at each device(that is, the time of the emitting of the sound and the time of thereceipt of the sound) and then repeating same process in reverse. Thenoted times can then be subtracted from one another, reflecting the timethat it takes to the sound to travel, and such values will cancelthemselves out, leaving twice the relevant time displacement remaining.

Orientation Detection—In discussing the processing of various inputs,such as those of accelerometer 145A and other sensors 145, it ispreferably that various inputs be identified and/or separated intoelements such as “forward acceleration”, “lateral acceleration” andsuch. These terms are relative to the car's coordinate system (e.g.“forward” is the direction of car's movement) while the raw inputs fromthe various sensors 145 are relative to the coordinate system of amobile device 105, 160 (it should be understood that while the presentexample is described with respect to a car, substantially similarapproaches can be applied to other vehicles as well). In order totransition (rotate) such inputs, the relative orientation of the mobiledevice 105, 160 within the coordinate system of the car is preferablyestablished. The following figures depict the various relativecoordinates of mobile device 105, 160, of a car, and of a mobile device105, 160 within a car:

FIG. 9A depicts the relative coordinate system of mobile device 105, asis known to those of ordinary skill in the art and referenced herein.

FIG. 9B depicts the relative accelerations and gyroscopic rotations of amobile device, as is known to those of ordinary skill in the art andreferenced herein. It should be understood that although mobile device105 is not shown in FIG. 9B for the sake of clarity, the variousrelative acceleration and rotations shown in this figure are relative toa mobile device in the same position as that shown in FIG. 9A.

FIG. 9C depicts the gyroscopic sign convention used herein, as is knownto those of ordinary skill in the art and reference herein.

FIG. 10 depicts the coordinate system used in relation to a vehicle(such as at vehicle data system 164) as is known to those of ordinaryskill in the art and reference herein.

FIGS. 11A-B depict mobile device 105 and its respective coordinatesystem in relation to a car and its respective coordinate system. Forexample, as will be described in greater detail below, in certainarrangements the respective coordinate systems can be transitioned, suchthat it is recognized, for example, that the +Z coordinate of the carcorresponds to the +Y coordinate of the mobile device 105, and the +Ycoordinate of the can corresponds to the −Z coordinate of the mobiledevice 105, as can be appreciated with reference to FIG. 11B.

Establishing the orientation of a mobile device 105, 160 within thecoordinate system of a car can be accomplished in a number of ways. Byway of illustration, in a ‘static’ approach, wherein it is assumed thatthe relative orientation of device 105, 160 is constant (e.g., if thedevice is attached to a cradle or is in the pocket of unmovingpassenger), the mean acceleration vector can be determined and beidentified as the “down” axis. The “forward” axis can be determined bycomparing/processing inputs from GPS 145C that correspond to directionangles with inputs from magnetometer 145E that reflect ‘north.’ Thethird axis can be computed based on the first two determined axes usingvector multiplication as is known to those of ordinary skill in the art.By way of further example, inputs from the accelerometer 145A, themagnetometer 145E and the GPS 145C (e.g., heading data) can be averaged,substantially in the manner described above.

In a dynamic arrangement, inputs originating at accelerometer 145A,gyroscope 145B and/or other sensors 145 can be processed to identifyreal-time changes in the orientation of a device 105, 160. In addition,acceleration/magnetic/GPS figures can be generated, preferably using“sensor fusion” algorithms, as is known to those of ordinary skill inthe art. In doing so, the above-referenced “static” approach can beutilized to dynamically determine the relative orientation of the device105, 160.

It should be noted that the gyroscopic sign convention adopted herein ispreferably such that if an observer positioned on the positive part ofthe axis of rotation sees the rotation as counterclockwise, it is deemedto be positive.

Low-Pass filtering—The values derived and/or computed from the variousinputs originating at the various sensors 145 of mobile device 105, 160can be frequently compromised by the vibration(s) present in car'senvironment (originating at the car's engine, road bumps, imperfectwheels, wind blowing through the windows, or even car audio sounds).Such vibrations can inject “noise” into the inputs originating at thevarious sensors 145, and can adversely affect the precision of theprocessing of the various algorithms disclosed here, both in terms ofefficiency and final accuracy.

There are various ways that this problem can be addressed. In onearrangement, one or more of devices 105, 160 within the vehicle areattached to a dampening device. In certain arrangements such a dampeningdevice can include one or more weight(s) that can be attached to themobile device 105, 160 to effectively increase its mass and thus make itmore vibration resistant. Additionally, dampening materials (e.g.sorbothane pads) can be attached to a device 105, 160 to prevent highfrequency vibrations from passing to the mobile device 105, 160. In anyevent, the inputs can be preferably processed with a bounded passfilter. On such example is an FIR with 128 taps with Hamming windows.

Sensor Fusion—As has already been noted and illustrated above, variousdeterminations can be made by processing inputs from several sensors 145together (e.g. forward velocity inputs originating at both theaccelerometer 145A and GPS 145C).

EXAMPLE 4

The following scenarios illustrate additional examples of the analyzingof a first and second input and identifying the presence of a first userand a second user (such as at step 720, above):

Using one or more biometric authentication methods (as are known tothose of ordinary skill in the art) to identify the presence of a firstuser and a second user. Such biometric authentication methods include,but are not limited to, voice recognition, fingerprint recognition, facerecognition, DNA identification, and retina identification.

The following are further examples of restrictions that can be employedat a mobile device 105, such as in the manner described in detail abovewith reference to FIG. 7. Various of these examples impede operation ofmobile device 105 by a driver moreso than they impede operation of thedevice by a passenger:

-   -   (a) If talking, the device is restricted to being held on the        left side (right side for U.K.) of the head/face of the user and        with an upright orientation, so that driver usage cannot be        hidden from external observers.    -   (b) If texting, mailing, browsing etc., mobile device 105 is        restricted to operating when having straight orientation (no        yaw) (adjustment can be necessary, in certain arrangements, for        a vertical/horizontal keyboard) and at least close to upright        orientation (cannot be on knee or low down so that driver cannot        “hide” the device use from external observers).    -   (c) The device interface will only function horizontally (more        difficult for driver to use).    -   (d) The device 105 is restricted to operating in one or more        ways only when camera 145F perceives a frequently moving        background (e.g., be held high, not hidden low in the driver's        lap or blocked by the steering wheel).    -   (e) The device 105 is restricted to operating in one or more        ways that can be determined to correspond to operation by a        passenger (and/or correspond to operation by a passenger of a        particular device), such as the various determinations described        in detail herein. By way of example, if no correlation (or,        alternatively, no negative correlation) is identified between        various typing tendencies and the speed, acceleration, and/or        maneuvering of a traveling vehicle, and/or a certain typing        accuracy threshold it met and/or maintained over a period of        time, it can be concluded that the user is likely a passenger.    -   (f) The device 105 is restricted to operating only when it can        be determined based on one or more inputs that the device is        under the control of a passenger and/or under the control of a        passenger using this particular device, such as the various        determinations described in detail herein. By way of example, if        relatively little “shake” is perceived at mobile device 105 over        a period of time, it can be determined that the device is under        the control of a passenger, as a passenger has the ability to        control “shake” by using both hands to steady the device—an        option not always available to drivers who generally need their        second hand to steer the vehicle.

It should also be understood that the various restrictions referencedherein can also be dependent upon the presence and/or absence of certainof the determinations disclosed herein. Thus, for example, variousrestrictions can be employed only when a device cannot be definitivelydetermined to be in the rear or on the right side of a vehicle (thussuggesting that a driver can potentially be operating the device).

EXAMPLE 5

In determining vehicle class or type, in certain arrangements adetermination is made as to whether one or more mobile devices 105, 160is/are present and/or in use in a vehicle. If such a determination isaffirmatively made, a further determination can then be made regardingthe general type or class of the vehicle (e.g., motorcycle, car, bus,train, boat, plane, etc.). This determination can then be used tofurther determine if there are restrictions on the mobile device usageon the part of a driver or the passenger in the vehicle. For example, ifit is determined through a signature analysis (that is, an analysis ofvarious patterns in various inputs) of an accelerometer 145A and/orgyroscope 145B and/or GPS 145C of mobile devices 105 and/or 160 thatthere is a high-likelihood that a particular mobile device 105, 160 islocated on a train, then that the mobile device 105, 160 can remainfully operational without any operation state restrictions (assumingthat no restrictions apply to anyone on the train including theconductor). If however, it is determined that a mobile device 105, 160is being used within a car, restrictions can be applied (e.g., no phoneuse at all or just no texting), particularly if it is determined thatthe user of the mobile device 105, 160 is the driver of the car, and nota passenger.

As described in detail above, the type or class of vehicle in which amobile device 105, 160 is located can preferably be identified and/ordetermined by using one or more of sensors 145 of mobile device 105. Incertain arrangements, this identification/determination can be improvedby using the onboard sensors of other mobile devices 160 and/or theonboard sensors (e.g., vehicle data system 164) of the vehicle in whichmobile device 105 is traveling. As noted above, being that differentvehicles operate in perceptibly different ways (which, in turn, reflectdifferent patterns that are perceptible to one or more of sensors 145),the signature of one or more of sensors 145 of mobile device 105 (and/orother mobile devices 160) present and/or used in relation to each of thefollowing vehicles is identifiable within a certain degree of accuracy:

It should be understood that in certain implementations, a device can beauthenticated (e.g., determined to be likely to be operated by a userwho is a passenger) if it can be determined that the user of the deviceis able to perform one or more actions (such as providing certaininputs) and/or demonstrate/provide evidence of certain situations (suchas providing photographic/videographic documentation of such situations)that a user who is simultaneously driving a vehicle would not bereasonably capable of doing. As described in detail herein, examples ofsuch methods of authentication include: if, while having determined thatthe vehicle (within which the mobile device is present) is in motion,the user of the device can be determined to be capable of (a) performingan action in a different part of the vehicle (such as in an area of thevehicle where the driver could not reasonably sit and/or reach); (b)holding his/her look/gaze (i.e., maintain focus of his/her eyes) in adirection (such as towards the mobile device) that is not towards theroad ahead, for a defined/sufficiently long long period of time; (c)using/interacting with the device with two hands for a sufficiently longperiod of time/performing one or more tactile gestures that requiresubstantially simultaneous use of both hands of the user (it should benoted that the terms “tactile gesture” and “tactile gestures” as usedherein are intended to encompass inputs and/or interactions that areprovided by a user in a tactile manner, such as through physicalinteraction with one or more media, elements, and/or components with oneor more fingers or hands of a user, examples of which including pressingbuttons, and performing gestures such as taps, swipes, and/or other suchinteractions with a touchscreen or touchpad); (d) configuring the deviceto record a visual capture (e.g., take a picture or video) within whichone or more indicators (that is, elements or aspects that can beperceived within the visual capture) that would be difficult/impossiblefor a driver to capture, are present (examples of such indicatorsinclude: (i) the presence of a passenger's seatbelt, as describedherein, (ii) the presence of a steering wheel with two hands on it, asdescribed herein, (iii) the presence of the eyes/face/smile etc. of theuser, as captured from below, above, and/or from the side (it can beappreciated that in scenarios where there is little or no external lightother than the interior overhead lighting of the vehicle, such as atnight, it can be preferable to take a picture from above and/or from theside, such that the overhead interior lighting within the vehicle doesnot interfere considerably with the visual capture) wherein the steeringwheel of the vehicle is not present in the visual capture, and/or (iv)the presence of the feet of the user in a position that isdifficult/impossible for a driver to achieve, etc.), etc.

As described herein, in certain implementations, the device user can beprompted to provide one or more inputs in order to authenticate thats/he is a passenger. Examples of such authentication methods/approachesinclude performing an action or a set of actions, such as providing oneor more alphanumeric inputs in response to a CAPTCHA prompt (as is knownto those of ordinary skill in the art), providing one or more inputsduring the course of interacting with a game, providing one or moreinputs in attempting to solve a puzzle, a lock screen, etc. It can beappreciated that such authentication approaches/methods can beconfigured to require a significant degree of concentration (and/orprolonged concentration) on the part of the user, such that suchauthentication approaches/methods are too difficult to be successfullyperformed (and/or consistently successfully performed) by a driver of amoving vehicle (who, presumably, must concentrate on the road ahead).Such authentication approaches/methods can be further improved byconfiguring them to require that (a) the authentication can only besuccessfully completed (e.g., authenticating the user of the device asthe passenger) when the user uses both hands simultaneously (asdescribed in detail herein); and/or (b) the authentication can only besuccessfully completed when the required inputs are provided such thatthe user cannot simultaneously see the road ahead while performing theauthentication (such as by making the user tilt his/her head and/or eyesdown or up or right or left, e.g., by requiring that the device be heldflat and/or placed in the user's lap or on the seat between the user'slegs, as described herein, and/or by requiring that the user lookdirectly in to the device in the manners described herein).

In another implementation, in order to provide the necessary inputs inorder to authenticate the mobile device (e.g., to authenticate a user ofthe device as a passenger in a vehicle), various restrictions canconfigure the mobile device to require that the device be placed or heldflat (such that the z-accelerometer of the device indicates theapproximate value of gravity, e.g., when the device is positioned in theuser's lap or on the seat between the user's legs,), and user tiltshis/her head so that the camera(s) of the device can detect the eyes,gaze, face, and/or smile etc. of a person (not necessarily limited to aparticular person), preferably for a certain minimum period of time(controlling, in certain implementations, for blinking and similareffects). It can be appreciated that such authentications can beachieved using a forward-facing camera (e.g., a camera on the side ofthe device that the screen is on in contemporary devices, such as theiPhone 4S produced by Apple of Cupertino, Calif., USA, and as isdepicted in FIG. 15F, wherein 145F₁ corresponds to a forward-facingcamera and 145F₂ corresponds to a rear-facing camera) and/or arear-facing camera (e. g., a camera on the side of the device that thescreen is not on in contemporary devices such as the iPhone 4s producedby Apple of Cupertino, Calif., USA).

It should be understood that in certain implementations, theauthentication methods/approaches described herein can be configured toauthenticate a user of a mobile device as a passenger upon determiningthe presence of the eyes/gaze/face/smile of the user, such as fromwithin a visual capture, only when such a visual capture can bedetermined to have been recorded while the mobile device was positionedin a manner/orientation that precludes/prevents the user fromsimultaneously seeing/focusing on the road ahead. (It can be appreciatedthat a driver operating the mobile device would generally only becapable of positioning the device in a manner/orientation whereby thedevice is able to capture his/her eyes/gaze/face/smile etc. while theuser is also able to see some portion of the road ahead.) This can bedetermined by (i) searching, such as with image processing techniquesknown to those of ordinary skill in the art, for theeyes/gaze/face/smile etc. of the user within a field of view that issmaller than the camera's field of view; and/or (ii) by requiring theangle of incidence between the user's eyes/gaze/face/smile etc. and thedevice be as close to (or as far from) 90 degrees (indicating that theuser is directly facing the device) as desired, such as in the mannerdepicted in FIG. 15G; and/or (iii) requiring that the ratio ofhorizontal pixels to vertical pixels of the user's eyes/gaze/face/smileetc. is consistent with the ratio present when a user looks directlyinto the device (and/or that the number of horizontal pixels and/orvertical pixels of the user's eyes/gaze/face/smile etc. is consistentwith the number present when a user looks directly into the device), asis known to those of ordinary skill in the art.

Moreover, in certain implementations, the authenticationmethods/approaches described herein can be configured to authenticate auser of a mobile device as a passenger only if the user holds the devicewithin a certain range of distance from her eyes/gaze/face/smile etc. Indoing so, it will be difficult, if not impossible, for a driver tofraudulently authenticate him/herself as a passenger by attempting toauthenticate the device by holding the device close to his/her head suchthat the resulting visual capture recorded by the device does notcontain any part of the steering wheel (as described herein). Thedistance can be determined, for example, based on the number of pixelsin the eyes/gaze/face/smile etc., relative to the resolution of thecamera and/or relative to the angle of incidence and/or using otherdistance measurement techniques known to those of ordinary skill in theart.

In certain implementations, the authentication methods/approachesdescribed herein can be configured to authenticate a user of a mobiledevice as a passenger upon determination that the user performed (and/oris capable of performing) one or more actions/provided one or moreinputs that can be determined to require(s) the use of one or two hands(e.g., swipe gestures at a touchscreen, including one or more times)such as in an implementation utilizing a forward-facing camera is used,and/or requiring a user to press a touchscreen with one or more fingersand/or touch one or more buttons on the device, irrespective of whetherthe camera is rear-facing or forward-facing), such as is described withreference to FIG. 15A.

It should also be noted that in certain implementations, when performingthe referenced authentication, it can be useful to configure the devicesuch that the user is required to (a) hold the device at a certainorientation, e.g., in landscape orientation, thereby making it moredifficult for a driver trying to falsely authenticate/unlock the device(which would otherwise allow the driver to perform certain actions),and/or (b) to encourage the user to hold the device in such orientationby having the device's screen display in landscape mode (that is,displaying the user interface in landscape mode, as described in detailherein), regardless of whether the device is actually held in alandscape orientation. It can be appreciated that such a configurationis relatively less of a burden on a passenger, as described in detailherein.

As referenced herein, in certain implementations, the authenticationmethods/approaches described herein can be configured to authenticate auser of a mobile device as a passenger only if no part of a steeringwheel is present in a visual capture, such as a visual capture of aportion of the user.

It should also be noted that in certain implementations, during theauthentication process, the mobile device can be configured to providingaudio and/or vibrational/tactile feedback to the user (such as in thecase of a forward-facing or rear-facing cameras, whereby the user can bedirected/instructed as to how to tilt/orient the device/camera in orderto achieve the requisite angle required by the particular authenticationmethod, as described in detail herein) and/or visual feedback (such asin the case of a rear-facing cameras and/or a forward facing camera)during the authentication process. In doing so, the user can be providedwith guidance/feedback, as needed, in order to enable the user toachieve the requisite input (such as a particular visual capture) inorder to authenticate the device, as described herein. FIGS. 15D and 15Edepict various examples of visual feedback that can be provided to auser during authentication.

By way of yet further example, in certain implementations, upondetermining that a device is in motion (or otherwise determining that atrip has begun) (such as in any number of ways described herein, and asdepicted in FIGS. 15H and 151), a user can be prompted or otherwisepresented with an interface that can enable the user to initiate anauthentication process, such as by interaction with a ‘slide to unlock’interface on a touchscreen, as shown in FIG. 15J. Upon successfullycompleting the ‘slide to unlock’ gesture, another interface can beprovided which incorporates/implements any number of variable inputtechniques. For example, a keypad (or keyboard, etc.) can be providedwhose position with respect to the touchscreen of the device can changebased on one or more inputs. By way of illustration, FIGS. 15K-15Pdepict how the position of a keypad on a touchscreen can change based onand/or in relation to the angle/orientation of the device (asdetermined, for example, based on the accelerometer and/or gyroscope ofthe device). As shown in FIGS. 15K-15P, the interface can be configuredsuch that the keypad is centered within the touchscreen when the deviceis held in a ‘flat’ orientation (as shown in FIG. 15Q and describedherein), while being positioned elsewhere on the screen (for example, ina manner that precludes a user from utilizing the entire keypad forinput) when the device is held in other orientations (as shown in FIGS.15K-P). As shown in FIG. 15Q, upon orienting the device in a ‘flat’orientation (and thus centering the keypad), the user can be prompted tohold their thumb (or another finger) in a specific region of thetouchscreen, such as in the manner described herein. Upon determiningthat the user is doing so (that is, maintaining his/her thumb/finger onthe specified region), the user can be presented with a sequence ofseveral numbers which are to be input into the keypad in order toauthenticate the user to the device as a passenger, as shown in FIGS.15R-T. Upon successfully inputting the presented sequence, the user canbe authenticated as a passenger and various aspects/functions of thedevice can be activated/unrestricted, as described herein. It should beunderstood that, in certain implementations, the sequence can allow forsome degree of user error (e.g., mistyping of the presented numericsequence into the keypad), while also preventing a user fromauthenticating in the event that the quantity of errors exceeds adefined threshold (as described herein). It should be understood thatthe described authentication sequence is exemplary and that any numberof modifications or adjustments or omissions to the sequence can beimplemented and are within the scope of the present disclosure. Forexample, instead of a keypad the user may be presented with a keyboardand a sequence of letters to input.

Moreover, in certain implementations, in lieu of requiring asubstantially ‘flat’ orientation (as shown, for example, in FIG. 15Q anddescribed herein), the referenced technique(s) can be employed inrelation to an orientation whereby the device is oriented, for example,such that the Y axis of the device (as shown in FIGS. 9A-9B anddescribed in detail herein) is substantially aligned with the directionthat the vehicle is traveling in, and the X-axis (as shown in FIGS.9A-9B) is aligned with the up/down of the vehicle (as shown, forexample, in FIG. 15C) or vice versa, i.e., with the Y-axis is up/downand the X-axis is collinear with the direction in which the vehicle istravelling. It can be appreciated that in order to achieve such anorientation, a user of the device will need to orient the device suchthat the user is facing towards the middle of the vehicle, or towardsthe side windows of the vehicle—but not towards the windshield (i.e.,the front) of the vehicle (thus preventing attempts by drivers tocircumvent such techniques by authenticating while diving). That such anorientation is consistent with the direction in which the vehicle istraveling can be confirmed, for example, based on a correlation of theGPS heading and the magnetometer/compass directional reading, asdescribed herein. Moreover, that such orientation is consistent with theX-axis up/down can be confirmed based on one or more inputs from thedevice's accelerometer, such as in the manner described herein. Itshould also be noted that while in certain implementations thereferenced techniques can be employed relatively consistently withrespect to the various users (i.e., the same or a comparable orientationcan be required of a user irrespective of whether he/she can bedetermined to be a driver or a passenger), in other implementations suchan orientation can be selected based on a determination as to whether aparticular user is likely to be a driver or a passenger (or adetermination as to whether such a user is positioned on the right sideor left side of the vehicle) as determined, for example, as describedherein. In such implementations, for example, the user can be directedto orient the device in a particular way (e.g., such that the user mustface towards the center of the vehicle in order to continue thereferenced authentication process). It should also be noted that thereferenced orientations are also exemplary and that any other suchorientation can be similarly implemented.

In another implementation, the referenced technique(s) can be employedin relation to a substantially ‘flat’ device orientation (as determined,for example, as described herein) and an orientation in which the Y-axis(or X-axis) of the device is oriented substantially up/down and theX-axis (or Y-axis) is substantially collinear with the direction inwhich the vehicle is traveling.

FIG. 47 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4705 a first visual capture can bereceived, such as from a first camera of a user device. At 4710, asecond visual capture can be received, such as from a second camera ofthe user device. In certain implementations, the second visual capturecan be received substantially concurrent with receipt of the firstvisual capture. At 4715, the first visual capture can be processed, suchas to identify a presence of a face within the first visual capture. At4720, the second visual capture can be processed, such as to identify apresence of a face within the second visual capture. At 4725, one ormore operations can be initiated, such as with respect to the userdevice. In certain implementations, the one or more operations can beinitiated based on (a) an identification of a face within the firstvisual capture and/or (b) an identification of a face within the secondvisual capture. In certain implementations, one or more restrictionsemployed with respect to the user device can be modified. In certainimplementations, a user of the user device can be identified as apassenger.

It should be noted that the techniques described herein can be employedin relation to and/or in conjunction with one or more passengerauthentication task(s) (including but not limited to numericinput-related tasks and video capture-based tasks, such as thosedescribed herein), including in scenarios where various otherelements/aspects/components (such as those described herein in relationto various passenger authentication tasks such as landscape orientation,thumb/multi-finger tasks etc.) are included/incorporated.

In another implementation, an authentication task can be employed suchthat the authenticator (e.g., a passenger) can be prompted to use acamera of the device (such as a rear-facing camera) to take a visualcapture that can be processed to identify the inclusion of the profile(or another angle shot) of another vehicle occupant's face/head (forexample, in lieu of a straight-on shot of the authenticator's face asdescribed herein). In addition, the authenticator can be required tohold the device such that the screen is substantially parallel tovehicle's side window(s) and/or in an orientation where the device'stouchscreen is facing the passenger's window. It can be appreciated thatin such an orientation a driver is relatively unlikely to be able totake such a picture. And, even in a scenario where the driver were socapable, one or more inputs originating at the device (corresponding to,for example, accelerometer movement, the centering of the visualcapture, etc.) can be processed to determine that such input(s) indicatethat a driver is likely to be attempting such an authentication task(and the authentication attempt can thus be denied). In addition, incertain implementations the referenced authentication task can alsoincorporate one or more of the other elements described herein (e.g.,landscape orientation, thumb/multi-finger tasks, number input tasks,etc.), thereby further reducing the likelihood that the referencedtask(s) can be performed by a driver, while also avoiding substantiallyincreasing the difficulty for a passenger to perform them.

In yet another implementation, an authentication task can be employedsuch that the authenticating user (e.g., a passenger) can be prompted touse the device's front-facing and rear-facing camera simultaneously (orin sufficiently close chronological proximity to one another and/orinterleaved) to take two visual captures, each of which can be processedto identify a presence of a human face/head (e.g., a driver and apassenger) therein. In addition, the authenticating user can be promptedto hold/orient the device such that the screen of the device issubstantially parallel to the vehicle's side windows and is alsopositioned in an orientation where the device's screen is facing thepassenger's window. In such a scenario, a driver is relatively unlikelyto be able to take such pictures. And, even in a scenario where thedriver were so capable, the one or more inputs originating at the device(corresponding to, for example, accelerometer movement, the centering ofthe visual capture, etc.) can be processed to determine that suchinput(s) indicate that a driver is likely to be attempting such anauthentication task (and the authentication attempt can thus be denied).In addition, in certain implementations the authenticating user can alsobe prompted to perform one or more of the other tasks, elements, etc.described herein (e.g., landscape orientation, thumb/multi-finger use,numeric input tasks, etc.), thereby further reducing the likelihood thatthe referenced task(s) can be performed by a driver, while also avoidingsubstantially increasing the difficulty for a passenger to perform them.

In yet another implementation, the authentication task can be employedsuch that the authenticating user (e.g., a passenger), can be promptedto use the device's front-facing and rear-facing camera simultaneously(or in sufficiently close chronological proximity to one another and/orinterleaved) to take visual captures, each of which can be processed toidentify a presence of a human face/head (e.g., a driver and apassenger) therein, whereby the front-facing camera (e.g., the user'scamera) provides a video capture that includes a substantiallystraight-on face/head shot. In addition, the authenticating user can beprompted to hold/maintain the position/orientation of the device suchthat that the screen of the device is substantially parallel tovehicle's side windows and is also positioned in an orientation wherethe device's screen is facing the passenger's window. In such ascenario, a driver is relatively unlikely to be able to take suchpictures. And, even in a scenario where a driver were so capable, theone or more inputs originating at the device (corresponding to, forexample, accelerometer movement, the centering of the visual capture,etc.) can be processed to determine that such input(s) indicate that adriver is likely to be attempting such authentication task (and theauthentication attempt can thus be denied). In addition, in certainimplementations the authenticating user can also be prompted to performone or more of the other tasks, elements, etc. described herein (e.g.,landscape orientation, thumb/multi-finger use, numeric input tasks,etc.), further reducing the likelihood that the referenced task(s) canbe performed by a driver, while also avoiding substantially increasingthe difficulty for a passenger to perform them.

It should be noted that in scenarios that incorporate video capture,similar imaging methods, and/or techniques can also be employed inconjunction with one or more cameras that are in communication with, butnot (necessarily) physically connected to the device (e.g., wearablecameras). It should be further noted that the techniques describedherein can be modified and/or adjusted accordingly to account for suchmodifications to the techniques described herein.

It should also be noted that, in certain implementations, variousaspects of the interface(s) depicted in FIGS. 15H-T can be configured tooperate (e.g., be presented on a touchscreen) specifically/only inlandscape mode/orientation. It can be appreciated that such anorientation can be more difficult for users who are drivers to interactwith, while being relatively easier for users who are passengers tointeract with.

Moreover, in certain implementations one or more time limits can beimposed on any/all of the elements/operations/steps in the referencedauthentication sequence(s). Additionally, in certain implementations,any number of elements, operations, steps, or aspects of the referencedsequence(s) can be configured to determine that a user is likely to be adriver or a passenger at varying/intermittent stages of the sequence.For example, a sequence can be configured to terminate upon adetermination that the device is not being held with at least a certaindegree of stability (as can be determined as described herein, such asbased on inputs from an accelerometer and/or gyroscope). By way offurther example, a sequence can be configured to terminate upon adetermination that the sequence (or any number of the steps/aspects ofthe sequence) is not completed within a defined timeframe.

It should also be noted that in certain implementations a user of amobile device can be authenticated as being a passenger even if thevehicle within which the device is present is not moving, e.g., byrecording a visual capture within which the driver's hand and thesteering wheel can be determined to be present, as described in detailherein.

Turning now to FIG. 15, a flow diagram is described showing a routine1500 that illustrates a broad aspect of a method for selectivelyrestricting operation of a mobile device 105 in accordance with at leastone embodiment disclosed herein. It should be understood that in certainimplementations, such selective restriction of a mobile device can beemployed in order to restrict operation of the device by a user who is adriver of a vehicle, while not restricting operation of the device (or,restricting operation of the device relatively less) by a user who is apassenger of a vehicle. Accordingly, it should be appreciated thatvarious of the determinations and identifications described herein aredirected towards one or more factors and/or aspects that are indicativein various ways of whether the user of the particular device is a driveor a passenger of the vehicle. Additionally, it should be furtherunderstood that the referenced method is preferably implemented insituations, scenarios, and/or settings where mobile device 105 ispresent within a vehicle, such as a moving vehicle. Various methods fordetermining a presence of the device within a vehicle and/or a movingvehicle are described in detail herein.

At step 1505, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step705. It should be understood that in certain arrangements, suchrestriction(s) are preferably configured, on average, to impedeoperation of mobile device 105 by a user that is a driver moreso thanthe restriction(s) impede operation of mobile device 105 by a user thatis a passenger, as described in detail herein. It should also beunderstood that a single restriction can be understood and/or configuredto be a combination and/or composite of multiple restrictions. It shouldalso be understood that in certain implementations the methods describedherein can be applied to a device that is already restricted, such as adevice that is configured, by default, to operate, in a restrictedstate.

At step 1510, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as one or more visual captures originating at mobile device105 and/or mobile devices 160 (e.g., from camera 145F), such as animage, a series of images, and/or a video, substantially in the mannerdescribed above with respect to step 710.

Then, at step 1520, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processes atleast one of the visual captures (such as those received at step 1510)to identify one or more indicators within the visual capture. It shouldbe understood that the terms “indicator” and/or “indicators” as used incontext of the referenced visual capture(s) are intended to encompassone or more items, elements, and/or aspects that can be distinguished,determined, and or identified within a visual capture, as is known tothose of ordinary skill in the art. That is, it can be appreciated thatin processing the one or more visual capture(s), the visual captures(e.g., images and/or videos) can be analyzed using one or more imageprocessing techniques, as are known to those of ordinary skill in theart. In doing so, one or more indicators can be identified within thevisual capture, and such indicators can preferably be further utilizedto determine if/how one or more restrictions are to be adjusted at/inrelation to the mobile device 105, as will be described in greaterdetail below.

The following are exemplary and non-limiting illustrations of variousvisual captures that can be received, and indicators that can beidentified within the respective visual capture:

In one implementation, a visual capture can include an image of at leasta portion of a face of a user, and such a visual capture can beprocessed to identify one or more indicators that reflect a steady gazeof the user. It can be appreciated that while a vehicle is in motion, apassenger in a vehicle is more likely to be able to maintain an ongoingsteady gaze into a camera of a mobile device than a driver who willnecessarily divert his/her gaze in order to see the road while driving.

In another implementation, a visual capture can include an image of atleast a portion of a face of a user, and such a visual capture can beprocessed to identify an absence of a steering wheel in the visualcapture. It can be appreciated that a visual capture that contains thepresence of a steering wheel together with at least a portion of a faceof a user indicates that it is likely that the user is in closeproximity to the steering wheel, and is thus more likely to be a driverof the vehicle. Thus, in visual captures where the steering wheel hasbeen determined to be absent, it can be determine that the user of thedevice which captured such a visual capture is likely to be a passenger.

In another implementation, a visual capture can include an image of oneor more feet of a user, and such a visual capture can be processed toidentify a position of the one or more feet. That is, it can beappreciated that a visual capture of the feet of a driver is likely toinclude one or more pedals (e.g., gas, brake, and/or clutch), and/or thepositioning of the feet of the driver, either on or around such pedals.Conversely, the absence of such pedals and/or the foot positioning thatthey entails, indicates that the user of the device which captured theimage capture is likely to be a passenger.

In another implementation, a visual capture can include an image of atleast a portion of a body of a user, and such a visual capture can beprocessed to identify a presence of a fastened seatbelt in a passengerorientation, as depicted in FIG. 15B and as will be described in greaterdetail below with respect to step 1720.

In another implementation, a visual capture can include an image of aninterior of a vehicle, and such a visual capture can be processed toidentify at least two hands and a steering wheel, as will be describedin greater detail below with respect to step 1542.

By way of further illustration in another implementation, a videocapture that reflects the scenery outside of a vehicle can be processed,such as using image/video analysis, to determine the orientation of themobile device. In order to do so, indicators such as the position of thesky and/or horizon can be identified within the in the visual capture,such as using image processing methods and approaches known to those ofordinary skill in the art. It can be appreciated that various aspects ofthe visual capture will necessarily change based on the orientation ofdevice 105 and/or the relative location of the device within thevehicle. It can thus be appreciated that in doing so, the orientation ofmobile device 105 and/or the relative location of the device within avehicle can be determined, as will be described in greater detail below.

At step 1522, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, preferably from at least one of the sensors 145 of mobile device105, a vehicle data system 164, and/or one or more other mobile devices160, substantially in the manner described above with respect to step710. It should also be understood that various inputs can be receivedfrom multiple sources (e.g., various sensors, devices, etc.). Forexample, inputs from accelerometer 145A and/or gyroscope 145B can bereceived, such inputs corresponding to an orientation of mobile device105. By way of further example, one or more input(s) from one or moretactile sensor(s) 145N, such as the simultaneous depressing of one ormore buttons, and/or the simultaneous tactile interaction of multiplepoints and/or locations on a touchscreen display.

At step 1524, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 processes the one ormore inputs, such as those received at step 1522, to determine apresence of a passenger within a vehicle. By way of example, inputs canbe received from vehicle data system 164, such as those originating atvarious sensors deployed within a vehicle, such as weight/heat sensorsthat are positioned within one or more seats, and/or sensors that candetect whether one or more seatbelts are/are not fastened. Such inputscan be processed in order to determine a presence of, and/or thelikelihood of the presence of, one or more passengers within a vehicle.

At step 1526, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 processes the one ormore inputs with the visual capture and/or the indicators to determine arelationship between the inputs and the visual capture and/or theindicators. That is, it can be appreciated that the processing of inputsfrom one or more of sensors 145 (and/or from other sources) togetherwith the visual capture/indicators can further enhance the accuracy ofdeterminations made and/or actions taken, such as the determination ofthe orientation and/or location of device 105, as referenced above. Forexample, inputs from accelerometer 145A and/or gyroscope 145B can beprocessed together with the referenced visual capture/indicators inorder to determine an orientation of the device 105 and/or a relativelocation of the device with increased accuracy. That is, it can beappreciated that if the visual capture/indicators reflect sceneryoutside the vehicle, such visual capture/indicators can be processed todetermine the direction in which the mobile device 105 is traveling. Forinstance, if a stationary item (and/or an item moving at a speed slowerthan the vehicle within which the user is traveling) identified in thevisual capture moves from left to right over the course of the visualcapture (such as the progression from Frame 1 to Frame 3 as depicted inFIG. 19), it can be determined that such a visual capture was taken withthe mobile device 105 being oriented such that the visual capture istaken from the right side of the vehicle. Accordingly, it can bereasonably concluded that the user capturing such a visual capture isnot the driver of the vehicle (who would be seated on the left side ofthe vehicle). Similarly, a stationary item identified in the visualcapture moves from right to left over the course of the visual capture(such as the progression from Frame 1 a to Frame 3 a as depicted in FIG.19), it can be determined that such a visual capture was taken with themobile device 105 being oriented such that the visual capture is takenfrom the left side of the vehicle, and thus it cannot be determined withcertainty that the user is not the driver of the vehicle. It can be saidthat such determinations reflect a relationship between the inputs andthe visual capture/indicators.

By way of further illustration, in one implementation, a relationshipcan be determined wherein preferably while the vehicle is in motion, theuser presses the device against the vehicle's right-side window with thedevice oriented so that the Y axis of the device (as shown in FIGS.9A-9B and described in detail herein) is pointed in the forwarddirection that the car is traveling in, the device is oriented so thatthe positive part of the X-axis (as shown in FIGS. 9A-9B) is facing upand the rear-facing camera of the device is facing out (togetherreferred to as the “required orientation”, as shown in FIG.15C)—something that in most circumstances only a passenger can do (itcan also be appreciated that the “required orientation” can beconfigured to account for cameras in other positions on the mobiledevice, such as a camera on the front face of the device—wherein it canbe appreciated that the negative side of the X-axis is to be facing up).Indicators can be identified, such as by processing the one or morevisual captures originating from the camera of the device to determineif the movement of pixels or blocks of pixels or features of interest inone or more successive visual captures are consistent with the devicebeing on the right window (e.g., if pixels in successive frame aremoving from left-to-right as opposed to right-to-left if the device wereon the left window), as are known to those of ordinary skill in the art.The referenced visual capture and/or indicators can be processed withthe one or more inputs to determine a relationship therebetween.

At this juncture, it can be appreciated that while implementations suchas those where the processing of a visual capture/indicators to identifythe direction in which stationary objects (and/or objects moving at aspeed slower than the vehicle within which the user is traveling) moveover the course of several frames (that is, left to right or right toleft) can enable a determination with a certain degree of certainty asto whether the visual capture was taken from the right side of a movingvehicle (indicating that the visual capture was taken by a passenger) orthe left side of a moving vehicle (indicating that the visual capturewas not necessarily taken by a passenger), in certain situations furthervalidation can be advantageous. This is because, in certain scenarios, adriver, though seated on the left side of the moving vehicle, can stilltake a visual capture that shows stationary objects moving from left toright. Accordingly, it can be appreciated that analyzing additionalinputs and/or factors can be advantageous in order to further determinethat a driver is not actually skewing the determinations referencedabove.

By way of example, in certain implementations, one or more inputs (e.g.,inputs originating at an accelerometer, gyroscope, magnetometer, camera,etc.) can also be processed (such as in the manner described in detailherein) in order to determine a stability of mobile device 105. Itshould be understood that any number of inputs and/or combinations ofinputs can be processed in order to determine the stability of device105. It can be appreciated that the degree of stability of device 105can be indicative of whether a user of the mobile device is a driver ora passenger in that in a scenario where a driver points device 105towards the right-hand window of the vehicle, it is likely that themobile device 105 is supported only by the hand of the driver within theinterior of the vehicle (it should also be recognized that given thefact that the driver must remain on the extreme left-hand side of thevehicle in order to operate the vehicle whose controls are situated onthat side, it is exceedingly difficult, if not impossible, for thedriver to effectively operate the vehicle while also reaching across thewidth of the car to the right-hand window). Given this positioning, amobile device 105 operated by a driver of a vehicle is generally subjectto considerable instability, especially when the vehicle is moving. Apassenger, conversely, who can be seated on the right side of thevehicle, generally has the ability to hold and/or position his/hermobile device 105 against the window, wall panel, and/or door of thevehicle. Doing so provides an additional measure of stability which isgenerally unattainable by a driver, as discussed above. As such, it canbe appreciated that by determining the stability of mobile device 105,and additionally, by identifying a relationship between the one or moreinputs and the visual capture/indicators, the systems and methodsdisclosed herein can better identify and/or account for operation of thedevice by drivers and/or passengers.

As noted in the example above, any number of inputs (both individuallyas wells as when processed in combination) can be analyzed in order todetermine the stability of mobile device 105. By way of furtherillustration, the visual capture/indicators themselves can beanalyzed/processed in order to identify the degree of “shake” present,in a manner known to those of ordinary skill in the art. That is, it canbe appreciated that multiple indicators can be identified from a singlevisual capture. For example, it can be appreciated that if an amount ordegree of “shake” can be detected in a visual capture (in addition toother indicators that can be identified in the same visual capture, suchas those described in detail above). In determining such anamount/degree of shake, it can be further determined that mobile device105 is likely positioned in an unstable manner (such as by being held ina manner other than by being positioned against a window of thevehicle), and thus has a significant likelihood of being operated by adriver of the vehicle. Various other inputs, such as inputs from thegyroscope 145B and/or the accelerometer 145A can also beprocessed/analyzed to determine the stability of the mobile device 105.

By way of further illustration, in certain implementations, in additionto identifying one or more indicators within a visual capture, asdescribe in detail above, determinations (such as those that can becomputed based on the indicators, such as that the user of the device isa driver or passenger of the vehicle) can be further confirmed/verifiedby processing the visual capture(s)/indicator(s) with one or more otherinputs in order to determine a relationship between them. For example,it can be appreciated that a determination that the mobile device ispressed against the window (as opposed to held by the user just lookingout of the window), in the required orientation, can be computed basedon inputs originating at the accelerometer and/or gyroscope and/or othersensors. In doing so, any number of determinations can be computed, inpart in order to confirm that the device is being held in a mannerconsistent with being pressed against a window. For example, (i) if itcan be determined that the device moves/shakes relatively less than itwould if it were held in a hand that is not supported by a window and/ordoor; (ii) if the device vibrates consistently with being held against awindow; and/or (iii) if the visual capture(s) of the mobile device donot contain pixel blocks indicative of the device not being againstwindow (e.g., near-fixed pixels on the borders of the visual captureshowing the door or the roof or the window frame of the vehicle, etc.)in the preferred/required orientation that is consistent with a userpointing the rear-facing camera of the device out the window of avehicle (wherein the camera sees light, the camera sees moving pixels,and/or the inward facing light sensor shows an amount of lightconsistent with pointing inward in the required orientation, as is knownto those of ordinary skill in the art).

In certain implementations, the device being pressed against theright-side window of the vehicle in the required orientation (asdescribed above) can be verified by processing one or more inputs, suchas those originating at the accelerometer, by tracking the movement ofthe device immediately prior to its being pressed against a window. If,before determining/validating that the device is pressed against awindow in the required orientation, and/or after accounting for changesin the orientation of the device during such period of movement, thedevice moved to the right relative to the direction in which the vehicleis heading, then it can be determined that the device has moved to theright-side window. This determination can preferably be computed basedon inputs originating at the accelerometer, the gyroscope, the GPSand/or the magnetometer, as is known to those of ordinary skill in theart. It should be understood that such approaches can operateindependently and/or in conjunction with one or more of the variousimplementations and approaches described in detail herein.

In other implementations, the user can be required to perform one ormore simultaneous tactile interactions with the device. One or moreinputs can be processed in order to determine the number of instances ofsimultaneous tactile interaction. As referenced above, examples of suchtactile interactions include the depressing of one or more buttons,and/or the simultaneous tactile interaction of multiple points and/orlocations on a touchscreen display (commonly known as “multitouch”), asis known to those of ordinary skill in the art. It can be appreciatedthat in certain circumstances, in order to provide two (or more) suchsimultaneous tactile interactions, a single user must use both ofhis/her hands. In other implementations, in order to provide six (ormore) such simultaneous tactile interactions, a single user must useboth of his/her hands (assuming that a single hand is capable of at mostfive simultaneous tactile interactions).

By way of further illustration, FIG. 15A depicts an exemplary lockscreen, in accordance with at least one embodiment disclosed herein. Itshould be understood that while FIG. 15A is exemplary, it illustratesvarious aspects of the various approaches described in detail herein.For example, area 1560 depicts various blocks where numbers arepresented to the user (such as at random). The user is prompted to inputeach respective number (e.g., ‘3’) as the number is presented. Inrandomizing the numbers presented, the user is effectively required tobe attentive to the numbers being presented (as opposed to repeatedlyinputting the same user-defined lock code). Area 1565 (depicting animage of a fingerprint) corresponds to an area within which the usermust maintain constant contact throughout the authentication/unlockprocess with at least one finger (as described in detail herein). Indoing so, the user effectively must dedicate one hand to such constantcontact, thereby necessitating that the other unlock procedures (e.g.,the inputting of the numbers, as referenced above) be performed with theother hand of the user—thus effectively requiring the user of both ofthe hands of a user (and thereby creating a situation whereby such aprocedure is difficult, if not impossible, for a driver of a vehicle toachieve, especially while driving). Moreover, a timer 1570 is employed,requiring that the user perform the required authentication within aspecified time period (as described in detail herein). Moreover, an‘Emergency Call’ button 1575 enables the user to initiate emergencycommunications even without authenticating/unlocking the device, as isalso described herein.

As referenced above, in certain implementations, various of thereferenced approaches can be employed in combination and/or in parallel.Such arrangements entail the processing of multiple inputs, and/ordetermining one or more characteristics associated with the operationstate of mobile device 105, including but not limited to: an orientationof mobile device 105, the relative location of mobile device 105 withinthe vehicle, a relative movement of mobile device 105, a stability ofmobile device 105, and/or a number of simultaneous tactile interactionswith mobile device 105. More particularly, it can be appreciated thatthe implementation of multiple approaches can further increase theaccuracy of the collective determinations above that of a singledetermination, and ultimately ensuring that operation of mobile device105 by a driver of the vehicle is prevented and/or restricted, whileoperation by a passenger is permitted. Moreover, such inputs and/ordeterminations can be processed with other such determinations, visualcaptures, and or indicators, in order to identify relationshipstherebetween.

For example, a visual capture can be processed to identify one or moreindicators, and/or to determine the orientation of mobile device 105and/or the relative location of the device 105 within a vehicle (usingthe various image analysis techniques described in detail above). Thevisual capture/indicators and/or other inputs can be processed todetermine the stability of device 105, as described in detail above(thus further ensuring that the device is not being operated by adriver), while also determining a number of instances of simultaneoustactile interaction, as also described above. In particular, given thatmobile device 105 will generally need to be supported against avehicle's window in order to achieve both a) the proper orientation toobtain a suitable visual capture that confirms the orientation and/orlocation of mobile device 105, and b) the requisite stability (providedby lodging and/or supporting mobile device 105 against the window, wallpanel, and/or door of the vehicle), it can be appreciated that achievingeven this degree of orientation/stability requires substantial ongoingcontrol of at least one of a user's hands, as depicted in FIG. 20.Accordingly, it can be appreciated that a user must generally use most,if not all of, the fingers from one of their two hands to orient thedevice in such a way for any period of time. Thus, it can be furtherappreciated that practically any simultaneous tactile interactions withdevice 105 would be exceedingly difficult for a driver of the vehiclewho also needs at least one hand to steer. As such, requiring furtherinteraction with device 105 (e.g., a multi-finger swipe motion in orderto unlock or otherwise unrestrict the device), in combination with theabove referenced determination(s), can further confirm that such adevice is being operated only by a passenger.

In certain implementations, a device can be verified to be operated by apassenger by requiring the user to physically interact with the device(e.g., perform a multi-touch or swipe) while the user is pressing thedevice against a window of the vehicle in the required orientation in amanner that is likely to require the use of a second hand. It can beappreciated that a driver of a moving vehicle cannot easily (if at all)press a device against the window in the required orientation, hold itstably and interact with it. Let alone on the window on the oppositeside of the vehicle (s)he is driving.

Then, at step 1542, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105. It should be understood that in various scenarios, adjustingan implementation of a restriction can entail employing one or morerestrictions, modifying an implementation of one or more previouslyemployed restrictions, and/or removing one or more previously employedrestrictions. It should be further understood that the adjusting,employing of, modifying of, and/or removing of one or more restrictionsat/in relation to mobile device 105 is/are preferably effected based onone or more of the visual captures, indicators, relationship(s), andpresences, and/or determinations referenced above. For example, based onthe identification of one or more indicators (e.g., identifying thepresence/absence of a steering wheel in a visual capture, such as avisual capture of the face of the user while the device is held in ahorizontal orientation), one or more restrictions can be employed (e.g.,if a steering wheel is present in the visual capture, indicating thatthe user is likely a driver) and/or removed (e.g., if no steering wheelis present, indicating that the user is likely to be a passenger). Byway of further illustration, based on a determination that device 105 ison the left (driver's) side of the vehicle, a restriction can beemployed whereby the mobile device is no longer receptive to userinputs. By way of further example, based on a determination that device105 is facing out the right-hand window of the vehicle and is relativelystable, one or more previously employed restrictions of mobile device105 can be removed.

At this juncture, it should be understood that in variousimplementations, the accuracy and/or efficacy of certain of thereferenced inputs that are received and/or processed can be compromisedwhen the vehicle within which the mobile device is present is engaged ina turn (as determined, for example, based on inputs originating ataccelerometer 145A, gyroscope 145B, or the magnetometer 145E and/orcompass 145M, and as described in greater detail herein). This is inpart due to the various forces that are present in a turning vehiclethat are perceptible by various sensors such as an accelerometer (e.g.,through the centripetal force shown on its z-accelerometer) and/orgyroscope, which are not present when the vehicle is travelingsubstantially straight. Thus, in certain implementations, the varioussystems and methods described herein can be configured such that variousoperations, such as the receipt and/or processing of various inputs isprecluded (and/or the results of any processing or determination thatincorporated such results is discounted, discarded, and/or ignored) whenit can be determined that the referenced vehicle is engaged in a turn,such as in a manner described in detail herein.

It should be noted that in certain implementations it can be useful toloosen one or more restrictions (e.g., have them appearintermittently—either at random, at some fixed rate or dynamicallyaccording to certain events) after the device user (who has alreadypassenger authenticated) has and/or continues to interact with thedevice in a manner that further suggests that the user is the passengerby, for example, (a) using the keyboard at a good speed; (b) using thekeyboard with low and/or consistent inter-key time variations; (c) usingthe keyboard with a low level of typographical mistakes; (d) exhibitingdevice movement that is consistent with that of a passenger.

Moreover, in certain of the implementations described herein, as long asa vehicle occupant does not successfully authenticate as a passenger(and, optionally, even if the user does), it can be useful to allow theuser to operate and/or interact with the device via voice (e.g.,voice-to-text, voice-to-command, text-to-voice). This feature canoptionally be limited to devices that are in a cradle and/or are beingused in a hands-free manner.

Turning now to FIG. 16, a flow diagram is described showing a routine1600 that illustrates a broad aspect of a method for selectivelyrestricting operation of a mobile device 105 in accordance with at leastone embodiment disclosed herein.

At step 1610, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or morevisual captures, substantially in the manner described above withrespect to step 1510.

Then, at step 1620, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processes atleast one of the visual captures (such as those received at step 1510)to identify one or more indicators within the visual capture,substantially in the manner described above with respect to step 1620.

At step 1622, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as a directional heading of mobile device 105 originatingat from GPS receiver 145C, substantially in the manner described abovewith respect to step 710.

At step 1623, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, such as a directional input 105 originating at from magnetometer145E and/or compass 145M, substantially in the manner described abovewith respect to step 710.

At step 1623A, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, computes one or moredeterminations, such as determinations reflecting orientation/positionof mobile device 105. By way of example, an input from the accelerometercan be received, preferably reflecting the X-axis position, and suchinput can be processed to confirm that the device is being held in therequired position with respect to the X-axis, such as in the mannerdescribed herein. Moreover, in certain implementations various of themethods described herein can be employed which determine the degree ofstability and/or the amount of “shake” present at the mobile device,based on which it can be determined whether the device is orientedagainst a door/window of a vehicle, such as in the manner describedabove with respect to FIG. 15.

Then, at step 1624, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processesthe received inputs, including the directional heading and thedirectional input, and such input can be processed to confirm that thedevice is being held in the required orientation with respect to itsY-axis. That is, it can be appreciated that the directional headingoriginating at the GPS can be correlated with the directional input(s)from the magnetometer/compass in order determine the orientation of theY-axis of mobile device 105, as is known to those of ordinary skill inthe art.

At step 1626, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 further processes therelative orientation of a mobile device, such as of a device held in therequired orientation with respect to its x-axis (such as that determinedat step 1623A), with at least one of the visual capture (such as thatreceived at step 1610) and the one or more indicators (such as thoseidentified at step 1620) to determine the device's relative orientation.It should be understood that in certain implementations, in doing so, itcan be confirmed that the device is being held in the proper Y-axisorientation, i.e., if the device's positive Y-axis is pointed in thedirection of the vehicle. It certain implementations, it may be usefulto compare the device's Y-axis orientation as determined in step 1624with the device's Y-axis orientation determined in this step. Such wouldbe particularly useful in correcting a situation where the device wasincorrectly placed on the left window of the vehicle in the requiredX-axis orientation and with the rear facing camera point out (i.e., tothe left side), but which rear facing camera was incorrectly identifiedfrom the visual capture to be pointing to the right because a vehiclethat was moving faster than the vehicle in which the device is presentwas seen in the visual capture. It should be further understood that incertain implementations the required orientation of the rear-facingcamera of the device facing out against the window can be confirmed,and/or can be confirmed/determined to not be held facing out of thewindow based upon evidence in the visual capture originating at thedevice (e.g., by determining whether or that one or more interiorcomponents of the vehicle, e.g., the window pane, door, etc., arepresent in the visual capture) and can be confirmed to be facing outagainst the right window based upon the direction of movement of objectsas is described in detail herein. It should also be understood thatvarious additional confirmation approaches can be employed, such asvarious multi-touch and/or 2^(nd) camera methods, such as thosedescribed in detail herein. It can be further appreciated that computingsuch a correlation enables the further determination of the relativelocation of device 105 within the vehicle. In determining theorientation of device 105, such as a mobile device held in the requiredorientation referenced above (as determined based on the GPS and compassheadings), the perspective of the visual capture can be furtherappreciated, thereby enabling the determination of where the user is/isnot seated within the vehicle, and thus to what degree of likelihood theuser is/is not the driver and/or passenger of the vehicle.

The required orientation consists of three parts: (1) X-axis, (2)Y-axis, (3) pressed against (right) window, (forward-facing camerapointing out).

Accordingly, it should be understood that the operations described withrespect to steps 1623A-1626 pertain to various aspects of the “requiredorientation” as described herein. It should be understood that the“required orientation” preferably consists of/incorporates threeparts/aspects/determinations: (1) X-axis, (2) Y-axis, and (3) that thedevice is pressed against the window of a vehicle, preferably with therear-facing camera of the device facing out.

Accordingly, it should be understood that inputs originating at theX-axis accelerometer can be processed to confirm that the device isbeing held in the required X-axis orientation, i.e., landscapeorientation, as described herein. Moreover, inputs originating at thecamera (i.e., visual captures) can be processed, wherein generallystationary/slower moving objects should move from left to right, and/orGPS heading can be processed against the magnetometer direction toconfirm the required Y-axis orientation, i.e., positive Y-axis indirection of vehicle's movement. It can be appreciated that doing soalso establishes that the camera (i.e., the rear facing camera) ispointing to the right. Moreover, the degree of “shake”perceived/determined at the device (as it can be appreciated that adevice shakes relatively less when held against a window than when heldby hand) and/or aspects determined based on the visual capture (beingthat a device held against window will not show interior components ofvehicle) can be processed to confirm that the device is pressed againstwindow. Based on the combined processing of these elements, it can bedetermined that the device is oriented at the right-hand side window ofthe vehicle, as described herein.

By way of further illustrations, it should be understood that one ormore of the above referenced implementations (e.g., the visual captureprocessing, the stability determination, etc.) can be further enhanced(or, alternatively, the present implementation can be employedindependently, without connection to any other of the implementationsdescribed herein) by verifying that the device is pressed against theright window in the required orientation by using the GPS sensor and themagnetometer and/or compass to verify that the orientation of the mobiledevice is consistent with being pressed against the right window of avehicle in the correct orientation (as described in detail above). Forexample, it can be appreciated that in a scenario where a device ispressed against the left-hand side window of a vehicle window in anattempt to fraudulently authenticate the device in the manner describedherein, such a device would still provide a GPS heading that isdiscernibly different than a device comparably positioned against theright-hand window of the vehicle Accordingly, even in a scenario whereother of the above-referenced implementations do not accuratelydetermine the identity of the use of the device (as a driver orpassenger), the present approach can provide an accuratedetermination/authentication of the identity of the user of the deviceas a driver or passenger.

Then, at step 1642, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thecorrelation, substantially in the manner described in detail above withrespect to step 1542.

Turning now to FIG. 17, a flow diagram is described showing a routine1700 that illustrates a broad aspect of a method for authenticating anin vehicle role of a user of a mobile device and/or modifying arestriction of a mobile device 105 in accordance with at least oneembodiment disclosed herein.

It can be appreciated that in order for a user to utilize thefunctionality of the integrated camera 145F of mobile device 105, such auser must grasp and/or come into contact with mobile device 105 with atleast one hand. As such, it can be further appreciated that a visualcapture taken by camera 145F that depicts two hands of a driver can bedetermined to be likely to have been taken by a user other than thedriver of a vehicle, as will be described in greater detail below.

At step 1705, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one or morerestrictions at mobile device 105 and/or in relation to mobile device105, substantially in the manner described above with respect to step1505. By way of illustration, in certain implementations suchrestrictions can configure the mobile device 105 to operate only inlandscape mode (that is, depicting the content/user interface shown onthe display of the mobile device be depicted only in a landscape, i.e.,lengthwise fashion) and/or in landscape orientation (that is, requiringthat the X-axis of the mobile device must detect gravity, as is known tothose of ordinary skill in the art—e.g., when held lengthwise—anorientation that generally requires two hands to effectively navigateand/or provide inputs to), as is known to those of ordinary skill in theart. By way of further illustration, in certain implementations suchrestrictions can configure mobile device 105 to receive various inputsonly when the mobile device is oriented at a defined orientation and/orwithin a defined range of orientations (as can be determined using theaccelerometer and/or gyroscope of the device). It should also be notedthat in certain implementations, the various restrictions employed at/inrelation to the mobile device 105 do not preclude partial and/or fulloperation of the device using voice commands, as is known to those ofordinary skill in the art. Moreover, in certain implementations, therestrictions do not preclude operation of the device for emergencypurposes, such as to call or text ‘911: as is also known to those ofordinary skill in the art.

It should be noted that in scenarios where a device is oriented nearlyflat (as if it were on a table) it can be difficult to determine whetherthe device is being held in portrait or landscape orientation, i.e.,whether the Y-axis of the device is pointed towards/away from the user(i.e., portrait orientation) or whether it is perpendicular to the user(i.e., landscape orientation) because the X and Y accelerometers, whichare generally used to determine such, have zero readings in thisorientation.

The portrait vs. landscape orientation of such devices can nonethelessbe determined in cases where the device is held/oriented in such “flaton a table” or nearly “flat on a table” positions based on observationsas to how the values associated with the accelerometer and/or gyroscopesof a device change over time and how the “flatness” of the devicefluctuates over time (as users generally cannot hold the deviceperfectly still). For example, a device that is determined to be nearlyflat and in portrait orientation (i.e., with its Y-axis pointed at theuser) will tend to have greater pitch than roll, whereas were the samedevice positioned in landscape orientation (i.e., with its X-axispointed at the user), it would tend to have greater roll than pitch. Assuch, devices that are held flat and that exhibit greater pitch thanroll can be determined to be in portrait orientation and, based on sucha determination, can be configured such that the user interfacepresented on their screens is also in portrait mode, whereas devicesthat exhibit greater roll than pitch can be determined to be inlandscape orientation and, based on such a determination, can beconfigured such that the user interface presented on their screens isalso in landscape mode, for example.

At step 1707, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, prompts a user ofthe mobile device 105 to initiate and/or provide one or more firstinputs at mobile device 105, substantially in the manner described abovewith respect to step 707. At this juncture, it should be noted that incertain implementations, such prompting includes the presentation,display and/or projection of prompts to the user in an obfuscated and/orobscured manner. That is, such prompts are preferably presented,displayed, and/or projected in one or more ways that require increasedconcentration and/or attention in order for a user to properly observeand comprehend/appreciate the prompting. Such obscuring/obfuscating ofthe various prompts/prompting serves to convey the information containedin the prompting (e.g., a word or string that the user must type) insuch a way that is relatively more difficult for a driver toappreciate/understand (given that the driver is likely to be distractedby and/or concentrating on various ongoing driving-related tasks) thanfor a passenger to appreciate/understand (given that the passenger isless likely to be so distracted/concentrated).

By way of illustration, in certain implementations, such as those inwhich at least some portion of the referenced prompting is conveyed tothe user visually (e.g., through the screen of the device), it can beuseful to have some or all of such information presented, displayed,and/or projected in a manner that makes it more difficult for someonethat is less able to pay close attention to the existence and/or contentof such visual information that is required to successfully complete therequired action(s), thereby increasing the difficulty for a user who isdriving to successfully complete the requested stimulus/input. Forexample, such visual information can appear for only a short period oftime and/or a non-constant time interval (including intervals of timethat contain random components) so that a driver of a moving vehicle,who is relatively less able to focus on such visual information, is morelikely to miss and/or not see it and/or not process such promptinginformation (or at least not comprehend/understand it as quickly as apassenger would, on average); thereby further preventing a driver of adevice from successfully unlocking such a device (and/or fraudulentlyauthenticating such a device as if the user were a passenger). Moreover,in other implementations, such prompting information can be displayed ina different manner (e.g., in a different location, orientation, color,font and/or shape), consistently and/or periodically. In doing so, itcan be appreciated that the ongoing changing of the manner or manners inwhich such prompts are presented, displayed, and/or projected introducesgreater unpredictability for the user viewing/expecting the prompting,thereby increasing the difficulty to the driver inanticipating/appreciating the prompting, as described.

At step 1710, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives at least afirst input. Such inputs can include, but are not limited to:alphanumeric inputs provided in response to a prompt (such as a CAPTCHAprompt, as is known to those of ordinary skill in the art), inputsprovided during the course of an interactive game, inputs provided in alock screen, inputs provided during the course of an interactive puzzle,one or more tactile gestures (such as one or more swipe gestures)provided at a tactile sensor such as a touchscreen of the mobile device105, one or more visual capture(s) and/or one or more inputs from one ormore of an accelerometer a gyroscope, a GPS receiver, a microphone, amagnetometer, a camera, a light sensor, a temperature sensor, analtitude sensor, a pressure sensor, a proximity sensor, a near-fieldcommunication (NFC) device, a compass, user interface, device buttons, acommunications interface, and a vehicle data system.

Then, at step 1720, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, processesthe one or more first inputs (such as those received at step 1710) tocompute a first determination, the first determination reflecting atleast one in-vehicle role indicator which relates to the in-vehicle roleof the user of the device as being either a driver or a passenger. Thisdetermination, reflecting an in-vehicle role of the user as adriver/passenger, preferably reflects an indication, such as one presentin a particular interaction with the mobile device 105, that the user ofmobile device 105 is/is not reflecting behavior that conforms with thatwhich can be determined to be associated with drivers and/or passengers.As will be illustrated in greater detail below, it should be understoodthat certain in-vehicle role indicators can enable determinationsregarding the role of a first user based on inputs such as visualcaptures that reflect aspects of another user (for example, if a firstuser takes a picture of a second user who is driving a car, it can bedetermined, based on an identification of the second user as a driver,that the first user is not a driver, and thus is a passenger), whileother in-vehicle role indicators can enable determinations based oninputs such as visual captures that reflect aspects of the userhim/herself.

By way of example, in one arrangement a visual capture (e.g., a digitalimage or video) can be processed, such as using image recognitiontechniques known to those of ordinary skill in the art, to identify,within the visual capture, two hands grasping a steering wheel. It canbe appreciated that a user grasping the steering wheel of a vehicle canbe determined to be likely to be the driver of the vehicle. However,based on the identification of two hands on the steering wheel, it canbe further determined that only a passenger in the vehicle is likely tobe capable of capturing such a picture using mobile device 105. (Itshould be understood that in certain implementations, further advancedimage processing techniques can be employed, whereby the two handsidentified on the steering wheel can be analyzed to determine that thetwo hands are substantially similar, and thus are likely to belong tothe driver—as opposed to the driver placing one hand on the wheel, andthe passenger placing another or the angle of the visual capture can beprocessed/analyzed to determine that the device is not likely to havebeen in a cradle or to require that the second camera of the device, ifavailable, also record a visual capture which can be processed to makesure there are no signs therein indicating that the driver performed thevisual capture, such as in the manner described herein.) Thus, it can beappreciated that in such implementations, while the visual captureitself depicts the hands of a driver, based on such a visual capture oneor more determinations can be computed regarding the likelihood that theidentity of the user that captured the picture (that is, the user of themobile device 105) is a passenger.

By way of further example, in another implementation a visual capturecan be received and processed, such as by using image recognitiontechniques known to those of ordinary skill in the art, to identify,within the visual capture, the positioning and/or orientation of a seatbelt in relation to a user. For instance, if the visual capture depictsa seatbelt as stretching from the right shoulder of a user to the leftthigh of a user, it can be reasonably determined that the pictured useris a passenger and not a driver.

By way of further example, in certain embodiments, an in-vehicle role ofa user can be determined if, the user can configure the device tocapture a visual capture that can be processed to identify one or moreindicators which, implicitly or explicitly indicate that there is apassenger in the car. (It should be understood that such visualcapture(s) are preferably captured while the vehicle is in motion, asdescribed in detail above). For example, as referenced above, if theuser is able to take a visual capture of two hands on the steeringwheel, the user of such device can be determined to be a passenger (as adriver generally cannot both take a visual capture with the device andhold the steering wheel with two hands). By way of further example, ifthe user of the device takes a visual capture within which a seatbeltgoing from the right shoulder of the user to left thigh of the user canbe identified, the user of such a device can be determined to be apassenger (being that a visual capture that a driver would take ofhim/herself is likely to show a seatbelt going in the oppositedirection).

At this juncture, it should be noted that in certain implementations,various other inputs, including but not limited to visual capture(s),can be received and/or processed in order to determine an in-vehiclerole of a user of mobile device 105. For example, mobile device 105 canbe positioned (such as in a dock) such that visual capture(s) receivedby/at the mobile device relate to a user's gaze (captured using afront-facing and/or rear-facing camera of the mobile device, dependingon the orientation of the device, as can be appreciated by those ofordinary skill in the art). That is, the visual capture can beanalyzed/processed using image processing techniques known to those ofordinary skill in the art, to identify the movements of a user's eyes,preferably while the vehicle is in motion (as can be determined based onvarious inputs, such as the accelerometer 145A). By way of illustration,if analysis of the visual capture reveals that the gaze of the eyes ofthe user of the device constantly and quickly returns to the directionof the windshield, it can be determined that the user is likely thedriver (as such a pattern would be typical of a driver who needs tomaintain ongoing view of the road while driving).

By way of further illustration, in certain implementations, anin-vehicle role of a user of a mobile device can be determined to be apassenger if, while the vehicle is in motion, the user is able toconfigure the device to take a visual capture based upon which it can beidentified (such as through image processing techniques as referencedherein) that the user is able to look (i.e., focus his head and/orgaze/vision) in a manner that only a passenger can and/or a drivercannot. For example, if it can be determined, such as through thereferenced image processing analysis of the visual capture, that theuser of the device is capable of maintaining a substantiallyconsistent/continuous look/gaze in the direction of the device for adefined period or certain periods of time, the in-vehicle role of such auser can be determined to be a passenger.

At step 1725, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, validates one ormore determinations, such as the determinations computed at step 1720.That is, as referenced herein, it can be appreciated that under certaincircumstances and/or scenarios, any number of determination approachescan be susceptible to error and/or fraud. As such, it can beadvantageous to further validate such determinations, thereby increasingthe respective accuracy of each determination. The particulars of suchvalidations will be described with reference to FIG. 17A.

Turning now to FIG. 17A, at step 1726, processor 110 executing one ormore of software modules 130, including, preferably, restriction module171, receives one or more second inputs, substantially in the mannerdescribed in detail above with respect to step 1710. In certainimplementations, such second inputs are preferably different inputs fromthose received at step 1710 (by virtue of the second inputs originatingfrom a different sensor and/or source, or by virtue of the second inputsbeing a separate input instance from the first input). By way ofexample, such second inputs can be received from the accelerometerand/or the gyroscope of mobile device 105.

At step 1727, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the secondinputs (such as those received at step 1726) to compute a seconddetermination, substantially in the manner described in detail abovewith respect to step 1720. In certain implementations (even those wherethe second input originates from the same source as the first input) thesecond determination is preferably independent of the firstdetermination, such as the determination computed at step 1720. By wayof illustration, the second determination (computed based upon inputsreceived from the gyroscope and/or accelerometer of the device) canreflect an orientation of the device, such as an orientation of thedevice with respect to the ground/earth. By way of further illustration,the second determination (computed based upon inputs received from thegyroscope, accelerometer, and/or GPS/magnetometer of the device) canreflect an orientation of the device, such as an orientation of thedevice with respect to the vehicle within which the device is present,as described herein. By way of further illustration, the seconddetermination (computed based upon inputs received from the gyroscopeand/or accelerometer of the device) can reflect a pattern or trend thatreflects the manner in which the vehicle within which the device ispresent is moving (e.g., reflecting acceleration, deceleration,stability, etc.). By way of further illustration, in an implementationwhere it can be determined that the focus of the user's gaze towards thewindshield (as identified based on the processing of a visual capture,as described herein) tends to increase during periods of acceleration,fast speed, and/or other movements, this correlation can indicate thatthe user is a driver (as a driver is likely to pay additional attentionto the road as such driving events occur). (It should be noted thatmobile devices 105 having dual cameras—that is, cameras on both theiranterior and posterior sides, as are well known to those of ordinaryskill in the art, are well suited for the referenced determinations, asthey enable visual captures of both a user's gaze as well as the sceneryoutside the vehicle's windshield.)

At step 1728, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, determines avalidity of at least one of the first determination and/or the seconddetermination. In certain implementations, the validity is determined bycomparing the determinations and/or identifying correlations,relationships, patterns, correspondences, and/or discrepancies betweenthem. By way of further illustration, in certain implementations, if itcan be determined, such as through the referenced image processinganalysis of the visual capture, that the user of the device is capableof maintaining a substantially consistent/continuous look/gaze in thedirection of the device for a defined period or certain periods of time,while the device is held in a certain manner, such as at a particularorientation (as can be determined, for example, using theaccelerometer/gyroscope of the mobile device 105), the in-vehicle roleof such a user can be determined to be a passenger. It can beappreciated that by requiring that the user maintain his/her look/gazetowards the mobile device while the device is positioned at a particularorientation, such as an orientation and/or a range of orientations thatentails the device being positioned substantially horizontally, a usercan effectively be prevented from simultaneously looking at the deviceand also looking at the road ahead. For example, in a scenario where theangle of the device (as can be measured/determined, for example, usinginputs originating from the accelerometer and/or gyroscope of thedevice) is oriented more than a defined threshold amount/number ofdegrees (e.g., 10, 20, or 30 degrees)(upward/downward/rightward/leftward or some combination thereof) fromthe typical line of sight of the driver in a moving car, such as isdepicted, for example, in FIG. 17B, the in-vehicle role of a user who iscapable of maintaining a substantially consistent look/gaze toward themobile device (as determined through an analysis of the visual capture,as described above) while the device maintains such an orientation canbe determined to be a passenger (since it is highly unlikely that adriver of a moving vehicle is capable of maintaining such a gaze towardsthe mobile device while the mobile device is so oriented, while alsoeffectively driving a moving vehicle). It should be understood that thereferenced examples are merely exemplary, and that numerous otherimplementations are also contemplated, utilizing other inputs, as can beappreciated by those of ordinary skill in the art.

At this juncture, it should be noted that in certain implementations,the various visual capture(s) referenced herein can be processed againstone or more databases, such as databases that maintainimages/photographs, and such processing can be further utilized indetermining the in-vehicle role of a user of a mobile device. Forexample, it can be appreciated that many regulatory agencies (such as adepartment of motor vehicles) maintain databases of images of alllicensed drivers within a particular jurisdiction. Moreover, it can beappreciated that certain mobile device users, such as children, thevisually impaired, and/or the elderly, can frequently travel in vehiclesdespite the fact that these individuals do not drive, by virtue of thefact that they are not licensed to drive. Thus, in certainimplementations, the visual capture of the face of a user can beprocessed against such a database that maintains photographs of licenseddrivers. Using image recognition techniques known to those of ordinaryskill in the art, if one (or more) photographs from the licensed driverdatabase are identified as substantially similar to the image capture ofthe face of the user of the mobile device, it can be determined that theuser is more likely to be a driver (by virtue of the fact that such auser is known to at least possibly be a licensed driver, and thus canhave a propensity to drive). Conversely, if no photographs from such adatabase are identified as being substantially similar y to the imagecapture of the face of the user of the mobile device, it can bedetermined that the user is more likely to be a passenger (by virtue ofthe fact that such a user may not even possess a license to drive).

By way of further illustration, the above referenced approach(identifying an in-vehicle role of a user based on the degree to whichthe user can focus his/her look or gaze) can be further implemented inconjunction with one or more of the other approaches described herein.For example, in a scenario where mobile device 105 is equipped with twocameras (e.g., a forward-facing camera which faces the user whenoperating the phone, and a rear-facing camera which faces away from theuser like most traditional cameras), by processing visual captures froma first camera facing the user and visual captures from a second camerafacing away from the user (and preferably outside a vehicle window).Based on the processing of such visual captures, a determination thatthe device is on the right-side of the vehicle can be computed (asdescribed in detail above), and/or a determination that the user is ableto maintain a prolonged gaze towards the device can be computed (as alsodescribed in detail above). In such a scenario, it can be furtherdetermined that the in-vehicle role of such a user of the device is nota driver, and one or more restrictions of the device can be adjustedaccordingly.

Then, at step 1742, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thedetermination and/or the validation, substantially in the mannerdescribed in detail above with respect to step 1642.

Turning now to FIG. 21, a flow diagram is described showing a routine2100 that illustrates a broad aspect of a method for selectivelyrestricting a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, including any and all of the implementations andapproaches described herein, it can be advantageous to initiallydetermine (e.g., by and/or based on inputs originating at vehicle datasystem 164) that there is a passenger present in the vehicle. It can beappreciated that if the presence of a passenger within a vehicle cannotbe initially determined, it can be more efficient to preclude any/all ofthe various methods and approaches described herein, such as those whichserve to identify the in-vehicle role of the particular user, and thussimply employ one or more restrictions based upon a determination thatthe user is likely to be the driver. Moreover, in certainimplementations, it can be advantageous to initially determine (e.g.,based on inputs originating at the mobile device 105 and/or externalsources such as vehicle data system 164) that the vehicle within whichthe mobile device 105 is present is in motion (being that certainrestrictions may be preferable/appropriate/necessary only when thevehicle is in motion).

At step 2110, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 receives one or moreinputs, substantially in the manner described in detail above withrespect to step 1710. For example, inputs originating at various sensorswithin a vehicle (e.g., seatbelt sensors, weight/movement/heat sensorsat a passenger seat, etc.) can indicate and/or be processed to determinethat a passenger is present within the vehicle. Put differently, one ormore sensors or sources (e.g., vehicle data system 164) can provideinputs and/or other such information that indicate and/or can beprocessed to determine that a vehicle is moving and/or that there areoccupants in the vehicle other than a driver. In certainimplementations, if no such inputs/notifications, etc. are received, andthus the presence of a passenger in the vehicle cannot be confirmed),any or all of the various methods described in detail herein willeffectively be precluded, as referenced above, such as by not adjustingany restriction/unlocking the device.

At step 2120, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, process the inputs(such as those received at step 2110) in order to determine a presenceof a passenger within the vehicle. That is, as referenced above, incertain implementations (which, as noted, can be employed independentlyor in conjunction with one or more of the various other implementationsand approaches described herein) one or more inputs originating at avehicle data system (e.g., OBDii or other in-car computer systems suchas seatbelt sensors, weight/movement/heat sensors in a passenger seat,etc.) can be processed to determining that there are one or morepassenger occupants in the vehicle (and/or a degree of likelihood ofsuch) and/or that more than one occupant is present in the vehicle(and/or a degree of likelihood of such).

Then, at step 2142, processor 110 executing one or more of softwaremodules 130, including, preferably, restriction module adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on thedetermination. That is, it can be appreciated that if the presence of atleast one passenger within the vehicle cannot be determined, the variousmethods and authentication approaches described herein can beprecluded/prohibited from commencing and/or made to fail regardless ofthe result of the other components, accounting for the fact that it isunlikely that a passenger is actually present in the vehicle, and thusthe user of the device within the vehicle is likely to be the driver.

It should also be noted that in certain implementations, various of themethods and approaches described herein, such as various approaches fordetermining an in-vehicle role of a user, can operate based on a defaultassumption/setting reflecting that the in-vehicle role of the user ofthe device is a driver, until proven otherwise (through one or more ofthe various methods described herein). In certain implementations such adefault setting can optionally allow the device user unrestricted accessuntil such time as such user wants to perform certain interactions thatrequire passenger authentication.

It should also be understood that the references provided above toholding/maintaining the mobile device at a particular orientation (suchas substantially horizontal) are non-limiting, and in certainimplementations various other restrictions, methods, approaches, etc.can be employed without requiring such orientation constraint.

It should also be noted that many of the implementations describedherein can be implemented alone and/or in different combinations.

It should also be noted that in certain implementations, any of thepassenger authentication methods/approaches described herein can beconfigured to require that certain components/aspects of theauthentication methods/approaches be performed at certain times withinthe process and/or within certain amounts of time and/or for certainamounts of time (e.g., the user must begin a swipe gesture within 1second of the phone being placed in the required orientation and must becomplete the gesture within 0.8 seconds thereafter during which time,for example, the user must place a finger in a certain location of thedevice for at least 1 second).

It should also be noted that the calculations, computations, and/orprocessing operations that are required in such authentication processescan be performed at the device itself and/or can be performed at aremote device (such as at central machine 168)—or in some combinationthereof, in a manner known to those of ordinary skill in the art.

It should also be noted that in certain implementations, theauthentication approaches/methods described herein are configured toprevent/preclude requiring a passenger to re-authenticate his/her devicewhen a vehicle temporarily stops or slows down (e.g., reduces its speedbelow a certain threshold), during the course of a journey. This can bedone, for example, by requiring that a the user of the devicere-authenticate only if the vehicle within which the device is presentcan be determined to have stopped and/or maintained a slow speed (e.g.,as can be determined based on inputs originating at the GPS,accelerometer, gyroscope, vehicle data system, antennas, radiofrequencies/signals, such as those originating at one or more radiotowers, such as those utilized in implementing cellular communicationnetworks, as is known to those of ordinary skill in the art, and/orother sensors), for more than a certain amount of time. In otherimplementations, the referenced requirement for re-authentication can becorrelated with a determination that the engine of the vehicle withinwhich the device is present is still operating (e.g., based on adetermination computed by processing one or more of inputs originatingat the accelerometer, gyroscope, magnetometer and/or microphone, asdescribed herein).

Turning now to FIG. 22, a flow diagram is described showing a routine2200 that illustrates a broad aspect of a method for eliciting anauthentication at a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, such mobile device preferably has one or moreauthentication modes, such as a first authentication mode and a secondauthentication mode. Moreover, in certain implementations, such a mobiledevice preferably has a single authentication mode having a range ofsettings/parameters that can be adjusted, as described in detail herein.

At step 2205, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs one a firstauthentication mode at/in relation to mobile device 105. By way ofexample, a first authentication mode can include a lock screen or mode(such as those referenced above at step 1710) wherein a user isprompted/required to provide alphanumeric input(s) in completion of aCAPTCHA exercise, complete an interactive puzzle, etc.

At step 2210, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives a firstauthentication attempt. For example, such a first authentication attemptcan include an input provided by the user in attempting toauthenticate/unlock the device, such as alphanumeric input(s) (in thecase of a CAPTCHA prompt), an input attempting to perform an interactivepuzzle, etc.

At step 2220, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the firstauthentication attempt to determine a degree of authentication success.For example, in the case of a CAPTCHA prompt, the first authenticationattempt (that is, the alphanumeric characters input by the user) can beprocessed to determine the degree to which the input was successful inperforming the task required to authenticate the device (such as thepercentage of characters in the CAPTCHA prompt that were properly inputby the user).

At step 2225, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs a secondauthentication mode based on the first authentication attempt. That is,it can be appreciated that in a scenario where the first authenticationattempt did not successfully authenticate the device and/or where thefirst authentication attempt did not meet a certain degree ofauthentication success (e.g., inputting at least 70% of the charactersin the CAPTCHA prompt correctly), a second authentication mode can beemployed. In certain implementations, such a second authentication modepreferably entails an authentication mode that is more restrictiveand/or more difficult to authenticate than the first authenticationmode. For example, the second authentication mode can require a certaindelay (e.g., 30 seconds) before another authentication attempt can bereceived at the mobile device. By way of further example, a secondCAPTCHA prompt can be presented requiring the user to input more lettersthan the first CAPTCHA prompt, and/or to input such letters moreaccurately, in order to authenticate/unlock the device.

At step 2226, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, maintains a log ofauthentication attempts. At step 2230, processor 110 executing one ormore of software modules 130, including, preferably, restriction module171, transmits one or more notifications regarding one or moreauthentication attempts, such as to a third party. It can be appreciatedthat in doing so, such authentication attempts can be monitored, andusers who consistently fail to authenticate their devices can beidentified as potentially attempting to authenticate their devices whiledriving.

By way of further illustration, it can be appreciated that in certainimplementations, such as those described above, it can be advantageousto make passenger authentication attempts, which come after failures toauthenticate, increasingly/progressively difficult. In certainimplementations, this can be achieved by requiring that a certainamount/duration of time elapse before a device, whose authentication hasfailed, can elicit and/or receive a re-authentication attempt. Such timecan also be configured to increase progressively after eachauthentication failure. Moreover, in certain implementations, suchauthentication failures can be reported one or more third parties.Moreover, in certain implementations, such authentication failures canentail one or more dynamic changes/adjustments to the parameters of thevarious techniques required to successfully authenticate (e.g., thedevice must be more stable on successive attempts in order toauthenticate).

It should also be noted that in certain implementations the details ofthe passenger authentication can be reported/transmitted to one or morethird parties, and corresponding logs can be established/maintained forthem.

Turning now to FIG. 23, a flow diagram is described showing a routine2300 that illustrates a broad aspect of a method for eliciting anauthentication at a mobile device 105 in accordance with at least oneembodiment disclosed herein. It should be understood that in certainimplementations, such mobile device preferably has one or moreauthentication modes, such as a first authentication mode and a secondauthentication mode. Moreover, in certain implementations, such a mobiledevice preferably has a single authentication mode having a range ofsettings/parameters that can be adjusted, as described in detail herein.

At step 2310, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. Examples of such inputs include, but are notlimited to, inputs relating to speed, location, road type, time of day,weather conditions, traffic conditions, (as received, perceived and/ordetermined based on one or more inputs of the sensors of a particulardevice, information and/or data received from one or more externalsensors and/or devices, such as, for example, external data streams, RSSfeeds, and/or databases, such as those accessible over a GPRS dataconnection, and/or computations and/or determinations that are computedbased on one or more of such inputs, information, data, etc.).

At step 2320, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to compute one or more determinations. Preferably thedeterminations reflect a degree to which a user, such as a user in amoving vehicle, is likely to be capable of multitasking and/or isdistracted and/or is potentially distracted or distractible. Forexample, it can be determined that a user of a device present within avehicle moving at a high rate of speed is likely to be more distracted(such as in scenario where such a user is the driver, on account of theincreased concentration that the driver must dedicate to driving at ahigher speed) and/or subject to the increasing force(s) (such as in ascenario where such a user is a passenger, especially while the vehicleis moving laterally), more so than a user in a vehicle moving at arelatively lower rate of speed.

At step 2330, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs anauthentication mode at the mobile device based on the determination. Itshould be understood that in certain implementations such anauthentication mode can include multiple parameters, settings, and orconfigurations, while in other implementations such an authenticationmode can be selected from among multiple distinct authentication modes,such as a first authentication mode and a second authentication mode.For example, as referenced above, it can be appreciated that a driverpresent in a vehicle moving at a relatively high rate of speed is likelyto be potentially more distracted, and thus relatively less able than adriver present in a vehicle moving at a relatively low rate of speed toprovide even a relatively simple authentication (while, at the sametime, a passenger in such a vehicle can be similarly limited, on accountof the forces imposed on the user while riding in such a fast movingvehicle). It can be similarly appreciated that a user traveling within avehicle moving at a relatively slower rate of speed is likely to be morecapable of multitasking, even while driving, than a comparable usertraveling within a vehicle moving at a relatively faster rate of speed,and thus can be determined to be relatively less distracted than such acomparable user traveling in a vehicle moving at a relatively fasterrate of speed. As such, in certain implementations, one of the variousauthentication modes and/or settings thereto can be employed/selectedbased on a determination that reflects the likelihood that the useris/is not distracted/able to multitask. Thus, by way of illustration, incertain implementations, when the vehicle is moving at a relativelyslower rate of speed, an authentication mode/setting requiringrelatively more concentration/attention can be employed (such as aCAPTCHA prompt requiring six letters to be correctly/accurately input inorder to authenticate/unlock the device), and when the vehicle is movingat a relatively faster rate of speed, an authentication mode/settingrequiring relatively less concentration/attention can be employed (suchas a CAPTCHA prompt requiring only four letters to becorrectly/accurately input in order to authenticate/unlock the device)can be employed.

By way of further illustration, it should be noted that any and all ofthe implementations, methods, and approaches described herein, includingthose enumerated above, can also be employed in a manner whereby thedifficulty of the task presented to and/or required of a user in orderto authenticate the in-vehicle role of a user as a passenger (includingthe time needed for a user to perform an action in order to soauthenticate his/her identity as a driver or passenger, and/or the timelimit within which the user is required to so authenticate), can bedetermined and/or adjusted dynamically based upon any number of factors.By way of example, factors such as speed, location, road type, time ofday, weather conditions, traffic conditions, (as perceived and/ordetermined based on one or more inputs of the sensors of a particulardevice, information and/or data received from one or more externalsensors and/or devices, such as, for example, external data streams, RSSfeeds, and/or databases, such as those accessible over a GPRS dataconnection, and/or computations and/or determinations that are computedbased on one or more of such inputs, information, data, etc., such as inthe manner described in detail herein) can be considered and/orprocessed in order to determine and/or adjust one or more operationalparameters of a particular authentication task/mode or tasks/modes, asdescribed above. For example, in a scenario where the vehicle withinwhich the user is traveling is moving at a relatively slow speed, theuser can be required to complete an authentication task within arelatively shorter time limit (as compared to when the vehicle is movingat a relatively faster speed), thereby accounting for the fact that whentraveling at a slower speed, a driver may be able to divert his/herattention from driving for a relatively longer time interval (ascompared to when driving faster). As such, the time limit within whichthe authentication task must be completed can be reduced at lowerspeeds. (Similarly, it can be appreciated that when traveling at fasterspeeds, a passenger may require additional time to complete anauthentication task, accounting for the additional forces attendant withtravel at higher speeds.) By way of further illustration, in certainimplementations the duration of time during which a particularauthentication task must be performed can also be adjusted dynamicallybased on any number of factors, such as those referenced above. Forexample, when a vehicle is traveling at a relatively slower speed, auser can be required to hold his/her gaze into a camera of a mobiledevice for a relatively longer period of time than such authenticationmay require when traveling at relatively faster speeds. Being that atslower speeds a driver may be able to divert his/her attention fromdriving for relatively longer periods of time (as referenced above), theauthentication task/mode can be adjusted (such as by requiring that thetask be performed continuously for a longer period of time) in order toaccount for this discrepancy/difference. It should also be noted that incertain implementations, the particular authentication task required ofa user (e.g., a swipe unlock gesture, a puzzle, etc.) can be changed orsubstituted depending on the various factors referenced above. Thus, forexample, at one speed a swipe unlock gesture can be required in order toauthenticate the user as a passenger, while at another speed a puzzlemust be completed in order to complete such authentication.

Moreover, in certain implementations one or more of the authenticationtasks/modes referenced herein can be stopped prematurely and/orcontinued indefinitely depending upon inputs received from one or moresensors that correspond to behavior of a user. For example, if, at somepoint prior to the end of such a task, the device is determined to belikely to be operated by a driver (e.g., the device or aspects thereofare moving in a certain manner that can be determined to resemble thatof a driver, such as (a) a relatively significant amount of ‘shaking’ ascan be measured/determined based on inputs originating at theaccelerometer and/or gyroscope of the device and/or (b) the manner inwhich the user input is provided can be determined to more closelyresemble that of a driver, such as based on relatively inexact keypresses, time to press keys, etc.), (a) the task can automatically beended prematurely in failure, (b) the task can be scored/registered asfailed, even despite the fact that the user may have completed theactual task successfully (and vice versa), and/or (c) the tasklength/time/difficulty is dynamically changed (i.e., the time in whichthe user must complete the task can be lengthened or shortened, thedifficulty of the task can be increased or decreased, etc.), such as inthe manner described herein.

In certain implementations, the authentication task can include elementsthat may require a response to be provided by the user (e.g., numbersthat are presented on the display screen of the device for a fixed ordynamic/random period of time), whereby (a) the element location on thedevice screen contains or otherwise incorporates a random or varyingcomponent/aspect (e.g., elements are placed in different locations onthe device display screen on different passenger authenticationattempts), (b) the element sizes contain or otherwise incorporate arandom or varying component/aspect, (c) the element orientations containor otherwise incorporate a random or varying component/aspect (e.g.,they can rotate around an axis, reflect through an axis, etc.), (d) thetime between the presentation of elements contains or otherwiseincorporates a random or varying component/aspect, and/or (e) the timeduring which the element remains on device's display screen contains orotherwise incorporates a random or varying component/aspect. It shouldalso be understood that, in certain implementations, the referenced taskelements can be arranged in a static manner (e.g., element 1 is placedat location A, in orientation B for as long as it appears) or can bearranged in a dynamic manner (e.g., element 1 is placed on the devicedisplay screen at location A and in orientation B, but moves fromlocation A to some other location (along any path, even a non-continuousone) and/or changes its on-screen orientation from orientation B to someother orientation (e.g., in any way, even if not necessarilycontinuous), such as for as long as it appears.

In certain implementations, the difficulty of any of the authenticationtasks described herein can be adjusted (e.g., up or down), such as basedupon the age of the user of the device (as can be determined, forexample, based on the adeptness of the user at completing such tasks).It can be appreciated that in many scenarios relatively younger userswill be more adept than older users. In addition, users who activelyengage in activities that are similar to such task (e.g., game playing,etc.), will be able to perform the task faster and with fewer errorsthan those who do not.

As such, for example, the younger and/or more adept a user can bedetermined to be, the harder the passenger authentication task that canbe presented to such user. For example, (a) the time to complete thetask will be shorter for a younger and/or more adept user than for anolder and/or less adept user, and/or (b) the substance of the task to beperformed by a young and/or adept user can be more difficult than thatfor an older and/or less adept user.

The age and/or adeptness of the device user may be (a) identified (e.g.,having been provided by a parent, an employer, etc.), (b) discovered(e.g., from auto-fill settings, social network information), (c)determined/estimated (e.g., based on the applications (e.g. games),installed on the device, the number of texts sent on average per unit oftime, the type of e-mail accounts on the device (e.g., work/corporatevs. not work), the existence of any connections that might suggestcorporate citizenship (e.g., Exchange/APN/VPN), the hours of activity,the speed of typing, the maturity of the prose used in messages, or anyother such indicators of the age/adeptness of a user of the device)and/or (d) learned (e.g., adjusted dynamically based upon the adeptnessdisplayed in relation to the device, such as in previous passengerauthentication task attempts).

Additionally, in certain implementations, an authentication task canrequire that at least one hand of the user be constantly engaged withthe device for substantially the entire task. For example, the user canbe prompted to place a finger on a certain part of the screen (whichpart of the screen may not be the same from trial to trial) or a certainbutton which the user is required to hold throughout the task (or elsethe task may end in failure), such as in the manner described herein inrelation to FIG. 15A. Alternatively, the user can be required to performa gesture with one hand, and to maintain the gesture throughout the taskin a manner that is perceptible by the device (e.g., by a camera).

In yet other embodiments, different tasks can be assigned to each of auser's hands. For example, one hand can be required to perform a fixedtask (e.g., maintaining contact with a particular area of the device,such as the screen, as described above), while the second hand isrequired to perform a non-fixed task (e.g., typing).

It should also be noted that, in certain implementations, it can beadvantageous to allow passengers to be authenticated by 3^(rd) parties,despite previous failed, inconclusive, incomplete, or non-existentauthentication attempts, such as the results of one or more of the abovereferenced methods. For example, if mobile device 105 is damaged ormalfunctions (e.g., due to a broken sensor, environmental disturbancessuch as weather conditions affecting the performance of the GPS, etc.)thereby precluding various of the authentication methods/approaches(such as those described herein) from being employed effectively, athird party such as an employer or a parent can remotely provide suchauthentication, such as in a manner known to those of ordinary skill inthe art.

It should also be noted that various of the methods described herein aredescribed with reference to a road system where the cars travel on theright-side of the road and where drivers are seated on the left-side ofthe vehicle. However, it should be understood that the methods describedherein are not so limited, and can be similarly employed/transferred toother road systems (such as that of the United Kingdom).

Turning now to FIG. 24, a flow diagram is described showing a routine2400 that illustrates a broad aspect of a method for selectivelymodifying a restriction employed at a mobile device 105 in accordancewith at least one embodiment disclosed herein.

At step 2410, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can originate at theaccelerometer and/or gyroscope of the mobile device 105, and reflect themovement/motion that the device perceives.

At step 2420, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to compute one or more trends/patterns. By way of example,inputs, such as those received at step 2410, can be processed todetermine one or more patterns, such as those that correspond to drivingand/or walking (e.g., by comparing the various inputs to operationsignatures that correspond to such activities, as is known to those ofordinary skill in the art). In doing so, one or more trends/patterns canbe computed, such as a trend/pattern that reflects that the user of thedevice is now walking. By way of further illustration, a trend/patterncan be computed reflecting the docking status of a mobile device, suchas in the manner described in detail herein.

At step 2442, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, and/orremoves one or more previously employed restrictions) based on the oneor more trends/patterns. For example, in certain implementations,despite having previously determined that the user of mobile device 105is a driver of a vehicle (and thus employing one or more restrictions onsuch a device), upon computing one or more trends/patterns that indicatethat the user of the device is now walking (and thus is no longerdriving a vehicle), such previously imposed restrictions can beadjusted, eased, removed, etc. By way of further illustration, based ona determination of the docking status of a device, as described indetail herein, one or more restrictions appropriate for a docked device(e.g., a restriction that prohibits voice calls to be made/conducted)can be modified/eased/lifted.

By way of further illustration, in certain implementations, after adevice is placed in driver mode (e.g., the user of the device beenauthenticated as a driver and/or the device and/or restriction areconfigured such that the device operates by default in driver mode,until the user can prove otherwise by way of one or moreauthentications, such as through the methods described herein) a furtherdetermination can be made with regard to whether the device remains oris no longer in a moving vehicle. In doing so, some or all of variousrestrictions referenced herein, e.g., operation of a mobile device in a‘driver mode,’ can be suspended and/or canceled, thus returning thedevice to its default, un-restricted operation. In variousimplementations, such a determination can be computed (for example,using inputs originating at one or more of the GPS, the accelerometer,the gyroscope, and/or the RF transceiver/antenna to know which celltowers the device is in communication) based on (a) whether the vehiclehas not moved above a certain speed for more than a certain period oftime; and/or (b) whether the vehicle has not moved above a certain speedfor more than a certain portion over a period of time (the ‘timeoutperiod’). Additionally, in certain implementations, a user who waspreviously identified as a driver can be enabled to authenticate thathe/she is no longer the driver of a moving vehicle in order not to haveto wait the full timeout period before regaining full control over thedevice. In certain implementations, this can be achieved, for example,(a) by holding the device so that the camera of the device can capture(and recognize, such as with face recognitions methods, as are known tothose of ordinary skill in the art) the presence of a face (or eyes orgaze etc.) and by then rotating 360 (or more or fewer) degrees, asmeasured by device's sensors (e.g., magnetometer, gyroscope,accelerometer, etc.), during which time the camera perceives the face(or eyes or gaze etc.); (b) by touching the device in a manner that canbe detected (e.g., touching the screen, holding a button, etc.) and bythen rotating 360 (or more or fewer) degrees, while the user maintainshis/her touch or hold on the device; (c) by moving the device (e.g., up,down, sideways) a distance greater than the distance that a driver in amoving vehicle is able to as measured by the device's sensors (e.g.,accelerometer, gyroscope, etc.); and/or (d) by taking a visual capturefrom close range of a license plate(such a visual capture can beprocessed to identify an indication of a degree of close proximity of alicense plate. It can be appreciated that a driver of a moving vehicleis likely to be incapable of capturing a visual capture within closeproximity of a license plate).

It can be appreciated that the referenced techniques are preferablyactions or tasks that are difficult, if not impossible, for a user toperform while he/she is still the driver of a vehicle.

Turning now to FIG. 18, a flow diagram is described showing a routine1800 that illustrates a broad aspect of a method for selectivelyrestricting an operation of and/or selectively modifying a restrictionemployed at mobile device 105, such as within a geographic area and/or adate/time window, in accordance with at least one embodiment disclosedherein. As will be described in detail herein, it can be appreciatedthat under certain circumstances (e.g., within defined spaces and/ortimes) it can be advantageous to control and/or influence the operationof one or more mobile devices 105, 160 in various ways, such as byconfiguring such devices to operate in a highly conspicuous/overtfashion. For example, considering the distracting nature of mobiledevice usage during class (particularly when used in an inconspicuousfashion), it can be advantageous for a school to require that itsstudents only operate mobile devices 105, 160 during school days/timeand/or on school locations/grounds and/or in certain location withinschool grounds (e.g., classrooms) in a manner that is highlyconspicuous, thereby effectively precluding the inconspicuous usage ofsuch devices 105, 160 in settings where their use is undesirable.

At step 1811, processor 110 executing one or more of software modules130, including, preferably, restriction module 171 generates one or moreoutput(s), such as an audio output (such as a beep or chirp) that isprojected through speaker 146 of mobile device 105. It should beunderstood that such outputs can be configured/adjusted in any number ofways (e.g., in frequency, duration, and/or volume), both with respect totheir substance (e.g., chirps, beeps, tones, etc.) and the periodicinterval within which they are projected (static and/or dynamic). In anyevent, it should be understood that such outputs are preferablyprojected at volumes and for durations such that inconspicuous operationof mobile device 105, 160 is effectively precluded (e.g., in a classroomsetting) on their account. Moreover, in certain arrangements it can bepreferable that such outputs are not so loud and/or so frequent so as tosignificantly annoy the user and/or those around them while using mobiledevice 105, 160 in a permitted setting. At this juncture, it should alsobe noted that in certain arrangements, one or more of the referencedoutputs can be generated in response to one or more inputs, as will bedescribed in greater detail below. It should also be noted that, incertain implementations, the referenced device can be configured togenerate/project such audio output(s) (e.g., ‘chirp(s),’ etc.)irrespective of one or more other settings (e.g., audio settings)associated with the device (so, for example, the device can continue to‘chirp’ even when set to silent/vibrate mode).

At step 1812, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs. For example, in certain implementations one or more of theoutputs projected by mobile device 105 (such as through speaker 146, asdescribed with reference to step 1811) can, in turn be received, asinputs, at the mobile device, such as through microphone 145D.

By way of further example, in other implementations the one or moreinputs can correspond to various user interactions with the device, suchas tactile interactions (e.g., with one or more tactile sensors such asone or more buttons, a touchscreen, etc., as describe in detail herein)or device movements. Upon receiving such inputs, one or more outputs canbe projected, as described above with respect to step 1811. (It shouldbe understood that in the referenced implementations, the sequence withwhich steps 1812 and 1811 occur are preferably reversed, such thatinputs are received, and then outputs are projected based on suchinputs. However, as noted herein, the various steps, operations, etc.,that pertain to and/or make up any and all of the various systems andmethods described herein should not be understood to be required to beperformed in a particular order or sequence. Rather, such steps can bearranged and/or performed in any number of sequences, as can beappreciated by those of ordinary skill in the art, and each suchsequence/arrangement should be understood to be encompassed by themethods and systems disclosed herein).

By way of further example, it should be understood that in certainimplementations, the systems and methods disclosed herein can beconfigured such that one or more of the output(s) that the mobile devicegenerates/projects upon/in response to a user input are not readilyaudible to humans, though such output(s) are perceptible to otherelectronic devices (e.g., a device used by a teacher and/or in theclassroom, such as the teacher's mobile device and/or other devices suchas devices configured to perform and/or provide the same or similarfunctionality), in a manner known to those of ordinary skill in the art.In such scenarios, various devices, such as a device used by a teacher,can be configured to perceive and recognize the referenced output(s)(that is, those output(s) that are not readily audible to humans butwhich may be in the audible range and not audible by virtue of theirshort duration (temporal summation) and/or their low volume). Moreover,such device(s), such as a device used by a teacher or administrator, canbe configured to generate and/or project another signal, such as asignal that is readily audible to humans. In doing so, the teacherand/or others can be alerted (by way of a human-audible signal/tone) tothe fact that a mobile device is in use within the classroom. It can beappreciated that such an implementation can be advantageous in certainsituations because in utilizing signals that are not audible to humans,potential distractions arising as a result of periodic/ongoingprojection of audible noises (as emitted from chirp-enabled devices) arereduced. Moreover, it should be understood that in certainimplementations a device, such as a device used by a teacher, canconfigure other mobile devices (such as mobile devices belonging tostudents present in the teacher's classroom and/or students in theteacher's class) not to emit readily audible sounds during times whenthe teacher sanctions use of mobile devices for his/her students, suchas for legitimate learning purposes. It should also be noted thatvarious of the implementations described herein can also be configuredsuch that a mobile device, such as a mobile device belonging to astudent, generates/projects output(s) that are readily audible to human.

In certain implementations, the referenced chirp-enabled mobiledevice(s) (e.g., a device belonging to and/or being used by a student)can be configured to receive a special output (such as a signal, asdescribed herein) originating, for example, from another device, such asa device controlled and/or operated by a teacher. As referenced above,in certain implementations, such output/signal can either be readily ornot readily audible to humans, whereupon the mobile devices that receivesuch signal preferably cease to chirp (that is, to project/emit anoutput as described herein) when the user interacts with the device forsome period of time or until they receive another signal that theyshould re-initiate chirping when the user interacts with the device (itshould be noted that in other implementations the device can, bydefault, not be in chirp mode, or cannot be in chirp mode on account ofthe teacher disabling it, and chirp mode in such devices can besubsequently activated by the teacher, such as by projecting theappropriate signal to such devices). It should be noted that suchspecial signal is preferably secure so that it cannot be readily emittedby all devices (e.g., non-Teacher Devices so as to unintentionally ornefariously disable chirping on chirp-enabled mobile devices. Methods ofensuring this security are known to those of ordinary skill in the art.In certain implementations it can also be useful to utilize two-waycommunication, including various forms of “handshaking” between themobile device(s) and the “teacher's device,” in a manner known to thoseof ordinary skill in the art.

At step 1815, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts one or moreaspects of one or more outputs based on one or more of the inputs. Thatis, in certain implementations the various device(s) can be configuredwhereby a device chirps in response to one or more external stimuli(e.g., one or more sounds) in a manner that configures the device tochirp more or less frequently and/or more or less loudly. For example, ateacher that hears a chirp, but is unsure as to which device in theclassroom emitted the chirp, can use his/her a mobile device or adifferent electronic device, mechanical device and/or physiologicalaction (e.g., his/her voice or a hand clap) to emit a signal which, uponreceipt and processing by chirp enabled devices, causes such devices tochirp, either in their usual manner or in an alternative manner (e.g.,in a more frequent and/or a louder manner). Additionally, in certainimplementations, one or more aspects of the outputs/chirps can beadjusted based on various determinations, such as a determination thedevice is operating in a regular/normal fashion for an extended periodof time (indicating that the present use of the device is likelypermitted), as described in greater detail below.

At step 1820, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the one ormore outputs and the one or more inputs. In doing so, a correlationbetween the one or more outputs and the one or more inputs can bedetermined. By way of illustration, in certain implementations a mobiledevice can be configured to chirp (that is, to generate/project anoutput), such as in response to a user's tactile input, such as a buttonpress or a tap/gesture at a touchscreen), and the mobile device can, inturn, receive/perceive such chirps by receiving them as inputs viamicrophone 145D. As such, a correlation can be computed, reflecting thedegree to which such outputs (that is, the chirps or signals projectedfrom speaker 146 of mobile device 105) correlate with the inputs (thatis, the sound of such chirps/signals) are, in turn, received bymicrophone 145D. It can be appreciated that if a strong/closecorrelation can be identified between such outputs/inputs, it is likelythat the mobile device is operating properly with respect to projectingand receiving chirp signals. However, if such a strong correlationcannot be determined, it can be determined that the mobile device mayhave been/has been tampered with, such as in order to prevent theprojection of chirp signals (e.g., if the user breaks and/or attempts tomuffle/mute speaker 146).

By way of further illustration, in certain implementations thepresence/absence of one or more input(s) and/or the presence/absence ofa correlation between a first input and a second input can bedetermined, while the device is within a defined geographic area and/orwithin a defined date/time window. That is, in certain arrangementsrestriction module 171 is configured such that one or more inputs (e.g.,depressing a button, interaction with the touchscreen, device movement,etc.) cause the outputting referenced above at step 1811. Thus, giventhat such inputs trigger the projecting of the referenced audio outputthrough speaker 146, it can be appreciated that microphone 145D can beeasily configured to have the capacity to detect such an output becausethe timing in which to look for the signals is exactly known to thedevice. Accordingly, if a presence of an audio output and/or a presenceof a correlation between a first input (e.g., a user depressing abutton) and a second input (e.g., detecting the audio output projectedby speaker 146 in response to the user's input at microphone 145D) isdetermined, the restriction scheme (that is a scheme requiring suchongoing ‘chirping’ in order to prevent covert operation of the mobiledevice) can be determined to be working properly, and no change oradjustment need be made (given that the restriction(s) are preferablyconfigured, in certain implementations, to allow the device 105, 160 tooperate in a conspicuous manner). However, if the presence of an audiooutput and/or the presence of a correlation between a first input (e.g.,a user depressing a button) and a second input (e.g., detecting theaudio output projected by speaker 146 in response to the user's input atmicrophone 145D) is not determined, the restriction scheme can bedetermined to be unlikely to be working properly. This malfunction can,in certain circumstances, be due to a user attempting to prevent mobiledevice 105, 160 from functioning properly, perhaps in hopes of avoidingthe referenced effects/restrictions. In such a case, where it has beendetermined that device 105, 160 is not operating properly, one or morerestrictions can be employed, modified, and/or removed. In doing so, theframework established can ensure that unauthorized use of the device105, 160 (e.g., during a class) is effectively precluded, except, incertain circumstances, such as in emergency situations. By way offurther illustration, it may be useful for the device to output sound(e.g., frequency, duration, volume) from its speakers and listen for iton its microphone, unrelated to the user's interaction with the device,and where such sounds are similar to the sounds that the teacher devicestransmit so that the device will not be blocked from receiving thesignals from the teacher's device if and when they are transmitted. Ifthe student device does not receive the signals so transmitted by thestudent device, i.e., the speaker and/or microphone are not workingproperly, the device will be restricted.

Moreover, in certain implementations, in response to such previouslydescribed external stimuli, only those devices that meet one or moreconditions (e.g., devices that have chirped within the last few minutes)are to chirp in response to one or more such external stimuli. Forexample, a teacher that hears a chirp, but is unsure as to which devicein the classroom chirped, can use a device or take an action to emit aoutput/signal which will cause chirp-enabled phones that meet thereferenced condition(s) to chirp in their usual or in an alternativemanner.

In certain implementations, the output/signal that the mobile deviceemits/projects upon user input can consist of two or more elements, atleast one of which is preferably audible. For example, thedetection/determination as to whether the device's speaker is workingproperly (as referenced herein) can be performed by having the deviceemit one or more outputs/signals, with or without connection to theuser's interactions with the device, that are not ready/easily audibleto humans (e.g., due to their frequency, intensity and/or duration), butwhich can also be perceived by microphone 145D (the “Detection Signal”),while another output/signal, which preferably enables teachers toidentify mobile devices that are in use (the “Teacher Signal”), can beat a frequency in the human audible range. It can be appreciated that byemitting/projecting the detection signal in a range or for durationsthat are not readily audible to humans, such a signal can optionally betransmitted louder, thus improving the signal to noise ratio (SNR),without distracting others.

Additionally, in certain implementations the Detection Signal and/or theTeacher Signal outputted/emitted from different mobile devices can varyacross different devices (it should be understood that in certain otherimplementations such signals/outputs can actually be the same signal).For example, such outputs can be randomized and/or altered by the userinput (e.g., different chirps correspond to different types of inputs,e.g., texting, game playing, etc.). This is useful as it can make thetask of detecting the chirp more accurate, easier, more power efficientand/or faster.

At step 1842, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions). That is, as referenced above, ina scenario where a close coordination can be identified between one ormore inputs and outputs, such a correlation can indicate that the‘chirp’ restriction is operating properly at the mobile device, and theemployment of such a restriction can be maintained. However, in ascenario where such a close correlation cannot be identified, thusindicating that the device may be malfunctioning and/or has beentampered with. In such a scenario, a further restriction can beemployed, such as a restriction deactivating all operation of thedevice. Finally, in implementations where the teacher's device (orsimilar) signals to the student's device to disable/enable chirp mode onthe student's device, the appropriate changes to the restrictions willbe made.

In certain implementations, the student devices can be restricted (e.g.,instead of being made conspicuous) as desired based on an instructionoriginating at a teacher device, i.e., the student device can be putinto ‘Class Mode,’ where one or more functionalities of the device arerestricted (e.g., all use is disabled except for emergency calls), whileTeacher Mode is on or for some period of time.

Turning now to FIG. 25, a flow diagram is described showing a routine2500 that illustrates a broad aspect of a method for selectivelyprojecting outputs at a mobile device 105 in accordance with at leastone embodiment disclosed herein.

At step 2510, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or moreinputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can originate at theaccelerometer and/or gyroscope and/or user interface of the mobiledevice 105, and reflect the movement/motion perceived at the device.

At step 2520, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s) to determine a first relationship (e.g., a correlation). By wayof example, inputs, such as those received at step 2510, can beprocessed, such as with one or more operation signatures. In doing so, arelationship between the inputs received and the operation signaturescan be determined.

By way of illustration, it should be understood that in certainimplementations, the ‘chirps’ referenced herein can be triggered basedon the movement of a mobile device, and/or a combination of user inputand movement. For example, inputs received from the accelerometer and/orgyroscope of a device (such as at step 2510) can be processed, such asby being processed with/against one or more operation signatures (thatis, data that identifies, such as based on mechanical and/or statisticalanalysis, how a device moves when engaged in certain activities, such aswhen a user is texting, walking, etc.). It can be appreciated that indoing so, the manner in which the device is being used can be determined(e.g., whether the device is being used to play a game, text, etc.),such as based on a correlation between the inputs and the operationsignature, For example, it can be appreciated that the signature ofvarious inputs originating at the various sensors when the device isbeing used to text, surf and/or play games is easily differentiable fromthe sensor signature of the device when the device is at rest and/orwhen the user is walking with the device on his/her person or in a bag,as is known to those of ordinary skill in the art.

At step 2522, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, projects one or moreoutputs based on the first relationship. For example, in a scenariowhere it has been determined (such as based on the relationship computedat step 2520) that the user is texting or playing a video game onhis/her mobile device, the device can be configured to project one ormore outputs (e.g., chirps), thereby creating a scenario whereby others(such as a teacher) can be made aware of such activity.

At step 2524, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes the one ormore outputs (such as those projected at step 2522) and one or moreinputs (such as an input received via a microphone, substantially in themanner described above with respect to step 1812). In doing so a secondrelationship, such as a correlation can be determined that reflects acorrelation between the one or more outputs and the one or more inputs,substantially in the manner described above with respect to step 1820.As described in detail above, it can be appreciated that in doing so, itcan be determined whether or not the speaker 146 of mobile device 105 isfunctioning properly (and thus is projecting outputs/chirps, such asthose projected at step 2522), or whether the speaker may have beentampered with, as described in detail above.

At step 2542, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions), preferably based on the secondcorrelation (as computed at step 2524), substantially in the mannerdescribed above with respect to step 1842.

Turning now to FIG. 26, a flow diagram is described showing a routine2600 that illustrates a broad aspect of a method for selectivelyconfiguring overt operation of a mobile device 105 in accordance with atleast one embodiment disclosed herein.

At step 2602, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, determines alocation of the mobile device and/or the current time/date. For example,using the GPS sensor of the mobile device, the location of the devicecan be determined. Specifically, in certain implementations, thelocation of the mobile device can be determined as being within adefined area or areas, such as within the grounds of a school, usingtechniques known as geofencing, as are known to those of ordinary skillin the art. In certain implementations, the presence of the device in anarea of interest (e.g., the school) can be detected/determined by thedevice by sensing the presence of the wifi signals associated with theschool's wifi transmitters and/or cell towers/base stations that areknown to be near the area of interest. By way of further illustration,the current time date can be determined from one or more sources (e.g.,the device's internal or remote clock/calendar, and/or a remote/thirdparty source such as the GPS time, the cellular time, the wifi networktime, etc.—i.e., sources that a user is potentially less likely to beable to tamper with).

At this juncture, it should be noted that in certain implementations,any or all of the following steps (2605-2642) can be employed based onthe determination at step 2602. Thus, by way of example, based on adetermination (at step 2602) that a mobile device is within a definedarea (e.g., a school) at a certain time (e.g., during school hours), arestriction can be employed at the device, as described with referenceto step 2605.

At step 2605, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, employs a firstrestriction at the mobile device. It should be understood that the firstrestriction preferably configures the mobile device to operate in anovert mode. It should be understood that the term “overt mode” as usedherein is intended to encompass one or more modes and/or operationalstates of a mobile device that configure the device to operate in such away such that operation of such a device by a user, on average, will bemore conspicuous to others in the vicinity/presence of the mobile devicethan if the device were not configured to operate in such a way. Anexample of such an overt mode is a restriction that configures thedevice to project an audible ‘chirp’ tone in response to every (or onlycertain) user input(s) received at the device, such as in the mannerdescribed in detail herein.

By way of further illustration, in certain implementations, an overtmode can include a restriction that restricts the mobile device toreceive one or more commands/actions/events (such as the command to senda message or email or open a message, and email editor, or a browser)only through voice commands. It can be appreciated that in doing so auser of the device will only be capable of sending a message by saying(or shouting) ‘send’ in an audible tone, thereby resulting in overtoperation of the device. It should be appreciated that such arestriction can be further employed together with/in parallel to otherrestrictions, such as restrictions requiring the user to perform one ormore tactile gestures (e.g., holding a finger on a region of atouchscreen while saying ‘send).

By way of further illustration, in certain implementations, an overtmode can include a restriction that restricts the mobile device toreceive one or more commands/actions/events (such as the command to senda message or email or open a message, an email editor, or a browser)only based on a ‘shake’ gesture (that is, a gesture that can beidentified as an ongoing significant deviation from the typical inputsprovided by the accelerometer/gyroscope of a device). It can beappreciated that in doing so a user of the device will only be capableof sending a message by shaking his/her device, preferably vigorously,thereby resulting in overt operation of the device. In otherimplementations, similar gestures, such as large/broad movements of themobile device, can similarly result in overt operation of the device. Itshould be appreciated that such restrictions can be further employedtogether with/in parallel to other restrictions, such as restrictionsthat entail the simultaneous projection of one or more chirps/signals,as described herein.

At step 2610, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, receives one or morefirst inputs, substantially in the manner describe in detail above withrespect to step 1710. For example, such inputs can correspond to one ormore user interactions with the device, such as the user typing anemail, playing a game, etc.

At step 2620, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, processes theinput(s). In doing so, a determination can be computed that reflects anoperation state of the mobile device. By way of illustration, based onthe location within and/or the time/date during which the device isoperating (indicating whether the device is/is not within schoolgrounds, and/or whether the device is/is not operating during schoolhours) in addition to the inputs received (reflecting a particularoperation or action being performed at the mobile device), adetermination can be computed reflecting the operation state of themobile device (e.g., a video game is presently being played in anon-school location during school hours, and/or a text is being sent ina school location during recess hours).

At step 2642, processor 110 executing one or more of software modules130, including, preferably, restriction module 171, adjusts animplementation of one or more restrictions at/in relation to mobiledevice 105 (that is, employs one or more restrictions, modifies animplementation of one or more previously employed restrictions, removesone or more previously employed restrictions, and/or maintains one ormore previously employed restrictions), preferably based on thedetermination.

It should be noted that in certain implementations, the transmission ofsignals to and/or the routing of signals received from all or certainmobile devices within a geo-area (which can be detected, for example,using the device's GPS and/or the wifi and/or the cellular tower/basestation and/or location information provided from the cellular carriersuch as DOA, AOA, signal strength) and/or in a certain date/time range,that are not chirp-enabled (i.e., not configured to chirp on user input)(and/or restricted such as in the manner described with reference toFIG. 26, such as where movement and/or and audible voice is required),is restricted. For example, a school's wifi network can be configured sothat it only transmits to/from mobile devices that were known to thewifi network to be chirp-enabled (and/or restricted such as in themanner described with reference to FIG. 26, such as where movementand/or and audible voice is required),or which mobile devices were on apre-defined list (e.g., using MAC addresses for teacher devices). Inanother example, one or more cellular carriers would only transmit(voice, data etc.) to mobile devices that are on a school's premises(e.g., within a geo-area) and in their cellular networks, that wereknown to the cellular network to be chirp-enabled (and/or restrictedsuch as in the manner described with reference to FIG. 26, such as wheremovement and/or and audible voice is required) or which mobile deviceswere on a pre-defined list (e.g., MAC addresses or UDIDs for teacherdevices). In both cases there can be exceptions for certain usage (e.g.,emergency calls, emergency text-messages) whereby the aforementionednetworks will allow such communications to pass through.

The following represents a logical flow that reflects the basicoperations of various of the implementations disclosed herein, in amanner that can be appreciated by those of ordinary skill in the art.

If chirping application is installed on device   If during school hours    If (device sees school wifi || device GPS shows in geo-fenced    area || device sees certain cell towers)       Beep when user inputs        If mic hears beeps           Allow free use         Else          Restrict as per usage policy     Else if GPS shows outsidegeo-fenced area       Allow free use     Else if no GPS signal      Assume in geo-fenced area   Else     Allow free use

At this juncture, it should be noted in certain implementations, variousaspects of the outputs/chirps projected by the mobile device can bedetermined/dictated based upon various determinations that can becomputed in relation to such outputs/chirps and the device's usage. Forexample, it can be appreciated that a device that is being used activelyand/or continuously by a user is relatively less likely to be operatingin a manner that is improper. As such, upon determining that a device isso operating, the device can be configured to chirp in a differentmanner (e.g., by adjusting the frequency and/or pattern and/or volume ofthe outputs/chirps).

At this juncture it should also be noted that the referencedrestrictions (e.g., geographic area and/or date/time can be, andpreferably are, established by a third party, such as a schooladministrator or parent. It should also be noted that the requiredgeographic determinations can be achieved using GPS receiver 145C usingstandard geofencing approaches known to those of ordinary skill in theart. Additionally, in certain implementations, one or more third partiescan optionally override various of the restrictions referenced herein.For example, in a scenario where one (or more) of the sensors at amobile device is broken or malfunctioning, it can be appreciated thatvarious authentication approaches may no longer be possible. As aresult, one or more third parties (e.g., a parent, telecommunicationsprovider, etc.) can override such restrictions, in order to account forthe malfunctioning/broken sensor, and thus enable the user to usehis/her device in an unrestricted manner.

In certain implementations, inputs originating at the magnetometer of adevice can be used/processed in order to determine if the device is in aclassroom or not by comparing a magnetic map that is presently perceivedat a device, such as in its current location, to a database of magneticmaps, such as for a school (or any other such location), and/or a set ofrules that define the areas in which students are and are not permittedto use their devices. Based on a determination that the magnetic map ofthe current location of the device can be matched to the magnetic map ofa location in which students are allowed to use their mobile devices,the usage of the device can be allowed. However, based on adetermination that the magnetic map of the current location of thedevice cannot be matched to the magnetic map of a location in whichstudents are allowed to use their mobile devices, the usage of thedevice can be restricted.

It should also be noted that, in certain implementations, the set ofrules defining the allowed and disallowed location(s) may be differentfor different devices and may change over time (i.e., based upon the dayand/or the time of day) and that the magnetic map database may residelocally, i.e., on the device itself, or remotely.

Moreover, in certain implementations, by (a) applying only to a devicethat is determined to be present on school grounds and/or during theschool day, and/or (b) applying to a device that is determined to be ina restricted device usage area, e.g., within a classroom (or at least isnot determined to be within a permitted area, e.g., a lunchroom), suchrestriction(d) can still be bypassed based upon whether and for as longas a teacher has configured the mobile devices in the classroom to allowfor their usage, such as in a manner similar to the one in which ateacher may configure devices in the classroom to temporarily not emitsounds as described herein.

It should be noted that whenever there is a signal (audible orinaudible) sent to or from a student device, such signal can also betransmitted via Bluetooth and/or WiFi.

It should also be noted that many of the techniques described hereinwith regard to reducing the power consumption on the device can apply tothe school/classroom setting as well where, in certain implementations,the various sensors of the device and/or other techniques are utilizedto determine whether or not the device is on school grounds.

It can be appreciated that people who make noise during movies distractthose around them. Mobile devices are a huge source of such unwantednoise. Accordingly, in one implementation, devices in a theater hall canbe configured to be selectively restricted while a movie is playing(optionally including its preview and trailers), but without restrictingsuch devices if they are outside the theater hall (e.g., at the popcornstand, in the bathroom, in the lobby, etc.).

In order to selectively restrict such devices by detecting that they arewithin a theater hall (e.g., during a movie screening), themicrophone(s) of the device can capture(s) and/or pass(es) audiorecordings (of some length, frequency, duty cycle, codec, format, filteretc.), such as to a remote server. Such recordings can be processed inorder to detect/determine whether the device is in the presence of ascreening/movie, such as by identifying sounds associated with aparticular movie (such as in the manner performed by Shazam for music),and/or by identifying sounds/patterns that are common to movies (orother media/events) in general. The identity of the particular moviebeing played can be identified and compared, for example, to a list ofcurrently running movies, such as in order to distinguish it from anolder movie (which may be relatively less likely to be screened within apublic theater).

This accuracy of such a technique can be improved by selectivelyemploying such techniques if the location of the device (e.g., asdetermined by its GPS, aGPS, BT, last known GPS, etc.) is firstdetermined to be in or near a movie theater. One way in this can beachieved is to use the GPS, if available, or alternative methods (celltower, wifi, BT), and/or using the last known GPS location.

It should be noted that while the user may cover the microphone of adevice, such as in an attempt to reduce the efficacy of thiscontext-detection technique, the device user will also not be able toeffectively engage in a voice conversation (the largest distracted moviewatcher problem) with a blocked microphone. It should also be noted thatthese techniques can also be employed in similar settings, such as wherepre-recorded audio is played and/or in settings where known live audiois played, e.g., classical theater, music concerts, speeches (with knowntext), etc.

In other implementations, a movie attendee who has exited (temporarilyor permanently) the theater in which a movie is being screened (e.g., tobuy popcorn) and whose device is still in “movie mode” (i.e., is stillselectively restricted), can provide a ‘self-declaration’ of thedevice/user being outside of the theater (e.g., using tactile, audioand/or visual input methods, such as those described herein), and, indoing so, can cause the movie detection mechanism to immediately (orrelatively more quickly) acquire sensor information and/or otherinformation to determine whether or not the device is still within moviecontext, in a manner that is relatively more expedient than would haveordinarily occurred. Such techniques can be particularly advantageous incases where, on account of power savings, the various data/informationacquired to determine whether or not the user is still viewing a movieare acquired with latency (e.g., with delay, in duty cycles, etc.)and/or at less than the fastest sampling rates possible. Accordingly,acquiring such data relatively more quickly (e.g., by triggering suchacquisition via the referenced ‘self-declaration’) can enable the deviceof a movie goer who exited a theater to have such a selectiverestriction lifted faster/sooner. Phrased differently, this techniquecan allow power-saving techniques to be applied more readily whilereducing the degradation to the user experience.

In other implementations, this problem can be solved (client-side only,server-side only or a combination thereof) by utilizing the digitalaudio watermarks/coded anti-piracy mark embedded within theater films(or inserting a similar or different mark into the film if such is notpresent within theater films or are otherwise ineffective for suchpurpose due to their frequency or other reasons) and such clientdevice(s) can be configured to be selectively restricted when (and foras long as) such mark is heard.

Moreover, in theaters within which sufficient network access (such as tocellular networks) is not present for such devices to properly utilizethe techniques described herein, such theater complexes can install oneor more access points as needed to facilitate such access. Moreover, theBSSIDs of these access points can provide additional locationinformation to geo-locate the devices within the theater complex (e.g.,inside a theatre, outside a theatre, etc.).

In other implementations, a hardware device can be installed within eachthe theater to be protected. While a movie is playing, such a device cancontinuously (and/or periodically) emit audio signals (inaudible,effectively inaudible and/or non-distracting) that can be perceived,recognized and/or interpreted by an appropriately equipped device toindicate presence within a movie theater having a live movie playing.Such a signal can be emitted at a frequency and/or at a volume that canprevent it from (and/or mitigate the likelihood of its) being heardoutside the theater. In another implementation, such signals can betransmitted over the in-theater sound system.

In another implementation, upon determining that the device microphoneis being blocked (when in or near a theater) so that the device does nothear the signal(s) necessary for it to identify that it is presentwithin a theater (e.g., the watermark, the special inaudible signal,etc., as described herein), such a device can be restricted or otherwisedisabled. For example, the device-based system can default to operatingbased on an assumption that the device is present in a movie, such as inthe same or similar ways described herein with respect to variousclassroom implementations.

In implementations with respect to which such watermarks or specialsignal devices may interfere with routine usage of a device in otherplaces/contexts (despite employing optional countermeasures that mayalso require positive geo-location data to determine that the device iswithin a theater in order to employ restrictions), thereby causing suchdevices to operate based on the assumption that they are present withina movie when they are actually not, the referenced in-theater signalscan be randomized and/or varied and/or crowd-sourced so that they couldnot abused. Various additional methods for securely delivering suchsignals are also contemplated, as known to those of ordinary skill inthe art.

It should be understood, with regard to any and all of theimplementations described herein, that while various of theimplementations have been described herein as being implemented by amobile device (for example, employing a restriction at a mobile device),it should be understood that any and all such embodiments can besimilarly implemented in relation to such a mobile device, such as, forexample, in a scenario where such a restriction is initiated/employed bya third party device such as a central machine that is capable ofcommunication with the mobile device. As such, all references providedherein that refer to a particular operation occurring at a mobile device(e.g., preventing a mobile device from a particular operation) should beunderstood to also encompass operations performed by an external/remotedevice which, in turn, can affect the operation of the mobile device(whether directly or indirectly), and all such implementations areequally within the scope of the methods and systems described herein.

Additionally, in certain implementations a communications provider(e.g., a cellular carrier) can optionally restrict the usage a device,such as the device operated by a driver of a moving vehicle. This can beachieved by determining if the device is in a moving vehicle and, if so,assuming that the device is a driver's (and restricting it accordingly),unless the device user has authenticated himself/herself as a passenger,as described herein.

In one implementation, a cellular carrier can determine whether thedevice is in a moving vehicle by analyzing successive location positionsof the device (as can be determined by cellular networks), pursuant,among other things, to government regulations/guidelines that requiresuch networks to be able to determine the location of a cellular device(such as in the case of an emergency), using such location positioningtechniques known to those of ordinary skill in the art, including butnot limited to methods for locating the device such as angle of arrival(AOA), time difference of arrival (TDOA), signal strength (device orcell-tower) and others.

In other implementations, a system/device can be configured toadaptively learn, over time, the context (e.g., moving in vehicle,stationary, etc.) within which a device is present upon receiving (or inthe absence of receiving) one or more data signals (e.g., pertaining toWiFi APs, cell-towers, locations or geo-areas, Bluetooth devices,accelerometer signals [e.g., corresponding to walking], etc.) and canthen determine the context of the device, alone or in conjunction withother data, upon subsequently receiving (or in the absence of receiving)one or more of such data signals, such as in the future.

For example, if, over the course of a sufficiently long and/orsufficiently recent period of time, it was determined that 98% of thetime a device was in range of a particular WiFi access point it was alsodetermined to be present within a moving vehicle, then it can be furtherdetermined that, upon subsequently determining that the device ispresent within range of that same WiFi access point (and, in certainimplementations, unless some other data, input, and/or indication to thecontrary has been received), the device can be determined to be presentwithin a moving vehicle.

For example, if, over the course of a sufficiently long and/orsufficiently recent period of time, it was determined that 98% of thetime a device was in range of a particular WiFi access point and didn'treceive a GPS signal (e.g., present deep inside a building) it wasdetermined not to be present within a moving vehicle, then it canfurther determined that, upon subsequently determining that the deviceis present within range of that same WiFi access point and not receivinga GPS signal (and, in certain implementations, unless some other data,input, and/or indication to the contrary has been received), the devicecan be determined not to be present within a moving vehicle.

It should be understood that, in certain implementations, the referenceddata can be maintained on a device-by-device basis (or user-by-userbasis) and/or aggregated across users (whether non-selectively, or,alternatively, selectively chosen in some manner, e.g., users withsimilar daily routines, users with similar home or work locations, etc.)such as using one or more ‘crowd-sourcing’ approaches/techniques, suchas in a manner known to those of ordinary skill in the art.

In another implementation, the cellular carrier/operator can receivelocation and/or speed information from the device itself, consisting ofGPS information and/or information from the one or more of the device'ssensors. For example, the cellular carrier can send requests to thedevice's SIM card to query the device's GPS and pass such informationback to the carrier. In another example, the carrier can requestinformation from a process running on the device which can obtain suchinformation from the GPS and/or the device's sensors. If no such processis running on the device (and/or if such a process cannot beinitialized), the carrier can identify such device to be a driver deviceand can further apply the associated restrictions, as described herein.The effectiveness of this method can be increased if the process and/orthe information coming from the process is authenticated and/orverified, so as to prevent the transmission of erroneous informationthat might otherwise trick a cellular carrier into thinking that thedevice is not in a moving vehicle. Such authentication and/orverification can be done in several ways, for example: (a) The GPSvalues sent from the device can be compared with those obtained directlyby the carrier network. If the carrier network is clearly showing thatthe device is moving, yet the data the device is passing to the carriershows otherwise, this can indicate a security problem; (b) the devicecan pass an authentication code to the carrier in a manner known tothose of ordinary skill in the art.

Additionally, in order to more accurately and/or more quickly and/ormore efficiently determine if the device is in a moving vehicle, thecarrier can combine location/speed information sourced from the carriernetwork with the information sourced from the from the device.

Upon receipt of such device location/speed information, the carrier candetermine whether the device is in a moving vehicle. In oneimplementation, if the speed of the device is greater than a certainthreshold speed, it is determined to be in a moving vehicle.

Upon determining that a device is in a moving vehicle and until suchtime that it is determined that such device is no longer in a movingvehicle, the carrier can restrict (partially or completely) theinformation that is sent to/from such device unless the device's userhas authenticated the device as a passenger device using, among others,any one of the passenger authentication methods described herein. Theeffectiveness of this method can be increased by ensuring that anypassenger authentication is trustworthy, so as to prevent thetransmission of erroneous information in order to trick a cellularcarrier into thinking that the device is being used by a passenger. Thiscan be done, for example, by authenticating the passenger authenticationinformation, using methods known to those of ordinary skill in the art.

Additionally, the cellular carrier can strengthen any such restrictionsby instructing the device's SIM and/or code running on the device itselfto further restrict the device (e.g., preventing wi-fi communication).

Moreover, various security measures can be employed to ensure that thedevice user does not trick the cellular carrier into providing data tothe device while the user is the driver. As example, a device that hasbeen ‘rooted’ or ‘jail-broken’ may not be allowed to authenticate as apassenger. As an additional example, various security options forcentrally (e.g., from a cellular data center) authenticating applicationdata sent from a mobile device can be employed, such as, (a) creatingnon-repeating data by incorporating in-data timestamps to make it harderto ‘replay’ data; (b) using a digital signature to sign data on thedevice before it is sent to the carrier, where a one-time key generationtime process can be employed to make this method even harder tohack/override; (c) performing such authentication at the operatingsystem level (e.g., within the kernel) to make it harder to replace thetrusted data with altered data; and/or (d) performing the authenticationat the hardware level. These techniques and similar ones are known tothose of ordinary skill in the art of computer security andcryptography.

It should also be noted that, in certain implementations, some or all ofthe various techniques and technologies described herein can beincorporated entirely or in part into the operating system of a device.In doing so, various operations can be relatively less susceptible touser interference/intervention, and also make the processes executingwith respect to the various techniques relatively more stable and/ormore energy efficient.

It should be noted that in some methods of passenger authentication (forexample, passenger authentication methods that incorporate a repeatedpass-phrase, pass-code and/or pass-action), the effectiveness of suchmethods can be increased by incorporating a protocol that furtherenhances security, by (a) running at least one component process of thepassenger authenticating process on the device in a manner that allowssuch component process to be authenticated against a central serverusing a pre-assigned private key that signs OS information about suchcomponents and/or other components by using a signed kernel module; (b)if the component process authentication succeeds, by having a centralserver send a phrase, code and/or action to the passenger authenticatingprocess on the device which, in turn, displays such phrase, code and/oraction to the user; and (c) sending the phrase, code and/or actioninput/performed by the user back to a central server, whereupon thecentral server only authenticates the device user as a passenger if thephrase, code and/or actions match those that were sent and are performedin a timely manner.

It can also be appreciated that it can be advantageous to intelligentlymanage use of energy/power at a mobile device, such as in any or all ofthe various contexts and settings described herein. Due in part to theirsmall size, mobile devices have energy constraints (e.g., limitedbattery power). Accordingly, it can be advantageous to identify andcontrol processes running on mobile devices that use energyunwisely/sub-optimally. Moreover, because mobile devices are nomadic,they are easily misplaced. Such misplacement, among other things,presents a security threat.

Accordingly, in certain implementations a context in which a deviceoperates (e.g., one or more of: moving, moving in a vehicle, moving in aparticular type of vehicle [e.g., bicycle, car, truck, bus, airplane],connected to a power source, battery state, user presence [as can bedetermined, for example, by screen state (on/off), lock screen state(on/off), keystrokes, button presses, camera, audio, proximity, heat,etc.], prompting the user to determine if the user believes that thecontext is such that the use of one or more device resources should bechanged, etc.) can be determined. Based upon the determined context(s),one or more resources used by one or more processes on the device can beadjusted (e.g., processes that use screen display, wake locks, sensorcalls, camera, speakers, microphone, RF, wifi, data communication,etc.), such as based on the determined context, thereby providingvarious benefits (e.g., energy savings, increased security, betterand/or more accurate information/determinations, etc.).

FIG. 33 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3305 an operational state of a firstsensor of a device can be determined. At 3310, an operational state of asecond sensor of the device can be selectively adjusted, such as basedon the operational state of the first sensor.

FIG. 34 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3405 a power connection status of adevice can be determined. At 3410, an operational state of a sensor ofthe device can be selectively adjusted, such as based on the powerconnection status.

In certain implementations, inputs originating at one or more of thesensors of a device (including but not limited to GPS, RF, Wifi, NFC,BT, accelerometer, gyroscope, camera, microphone, magnetometer, lightmeter, proximity sensor, temperature sensor, compass, keyboard, buttons,etc.) can be used/processed to determine if the device is moving and/orwhere the device is located. If it is determined that the device is notmoving for more than a certain period of time (e.g., 5 minutes),applications that are employing a ‘wake lock’ (e.g., a screen wake lock,a CPU wake lock, a GPS wake lock) can be cancelled and/or modified. Forexample, many navigation applications (e.g., Waze) that run on mobiledevices use wake locks to override the screen lock settings of thedevice in order to keep such applications continuously visible to thedevice user. Such wake locks are often static, i.e., for as long as theapplication is running (e.g., in the foreground), the wake lockpersists. Accordingly, upon determining that the device is not movingfor some period of time (e.g., no significant GPS changes for 5minutes), a wake lock of such applications can be overridden (therebyenabling the lock to be disabled). Such techniques can be particularlyapplicable with respect to applications or processes that alreadyacquire and/or use location based information and/or movement basedinformation because little to no or additional energy expenditure islikely to be required to employ the operations disclosed herein.Moreover, such context-based resource management determinations andoperations can also enable certain security benefits. For example, in ascenario where a device was running a navigation application (e.g., onethat implements a screen/CPU wake lock) and the user forgot the devicesomewhere (e.g., in a vehicle, in a restaurant, etc.), the screen of thedevice will not lock (on account of the screen/CPU wake lock whichcontinues to be employed), thereby allowing anyone who finds the deviceto easily access the information on the device. By adjusting the deviceresource usage (in this example, the screen usage of the device as aresult of its wake lock) based upon its context, it can be determinedthat this device was not moving and its wake lock can be overridden,thereby preventing access (or further access) to the device by unwantedpersons.

In another implementation, a wake lock can be controlled dynamicallybased upon the location of the device as determined by inputsoriginating at one or more of its sensors in conjunction with and/orseparate from the movement of the device as also determined based oninputs originating at one or more sensors. For example, if the device isdetermined not to have moved for some period of time, but is determinedto be within a certain distance of a specific location (e.g., the homeor office of a user), the wake lock can be overridden according to onerule (e.g., wait a relatively longer time before overriding the wakelock is), whereas if the device is not determined to be near such alocation, the wake lock can be overridden according to a second, morestringent rule (e.g., wait a relatively shorter time before overridingthe wake lock).

It should also be noted that overriding a wake lock can be implementedin various forms (e.g., canceling the wake lock altogether, changing thetype of wake lock (e.g., from a bright wake lock to a dim wake lock),and/or canceling the wake lock and taking an action like dimming thescreen).

It should also be noted that the ability to control device resources(e.g., by controlling wake locks) based upon their device's context(e.g., by determining if the device is moving and/or it location) so asto reduce energy expenditure and/or improve security can also enable theimplementation of processes and/or applications that have heretofore notapplied certain resource intensive techniques (e.g., wave locks, sensorsampling) because of the referenced energy consumption and securityconcerns, thereby enabling responsible/sustainable employment of suchresource intensive techniques and, in so doing, allow their users accessto better and/or more accurate information and a better user experience.

In certain implementations, if a device is determined to be oriented ina ‘flat’ orientation (e.g., resting on a table, as can be determined,for example, based on one or more accelerometer inputs) and also ‘upsidedown’ (i.e., with the screen of the device facing downwards, such astowards the table, which can also be detected one or more accelerometerinputs), then it can be determined that the user is unlikely to belooking at the screen of the device. Accordingly, based on such adetermination (and, in order to save power), the display/screen of thedevice can be turned off/dimmed, or otherwise deactivated, even beforethe device's ordinary screen timeout would have otherwise turned it off.Such a state/status with respect to the display/screen can be maintaineduntil, for example (i) the screen is activated (such as upon receipt ofan input, button press, etc.), (ii) the orientation of the device isdetermined to have changed so that it is relatively more likely that theuser is using (or may wish to be using) the screen, and/or (iii) theorientation of the device is determined to have changed (as in (ii))within a certain period of time, otherwise the screen can remaindeactivated (despite orientation changes) until the screen isaffirmatively activated (as in (i)).

In another implementation one or more of the sensors that are used byany of the processes running on the device can be controlled dynamicallybased upon the device's context. For example, the accelerometer of thedevice can be used to determine that the device is not moving, and, as aresult, a process that uses the (much higher energy expenditure) GPS canbe stopped and/or the rate at which such process uses the GPS can beslowed (in certain implementations, even to zero). Such dynamic controlof sensors can be effected in various ways. For example, from within aparticular process itself (in the GPS example, the process using the GPScan register to receive GPS information less frequently), through themechanism that controls the sensor readings and/or the distribution ofthe information therefrom (in the GPS example, the device can beconfigured to acquire GPS information relatively less frequently).

In another implementation, power connection state, status, and/orcontext of a device can be determined, i.e., whether or not the deviceis connected to a power source. If it is determined not to be, processesrunning on the device can be notified accordingly and can selectivelyreduce the resources that they are using. If the device is determined tobe connected to a power source, the processes running on the device canalso be so notified and can selectively increase the resources that theyare using. Determination of the context can be further refined by alsotaking into account the level of charge of the device's battery. Forexample, if the device is not connected to power, but its battery isfully charged, it can be reasonable for processes to use resources moreaggressively, whereas if the battery not fully charged, processes can beconfigured to lower their use of power intensive resources.

It should also be noted that the context determination(s) describedherein can be implemented within an application/process and/or byanother process on the device (e.g., a user process, a system process)which distributes or makes available such context information to otherprocesses, such as those running on the same device (e.g., via an API).Moreover, parts and/or aspects of the context determination(s) can alsooccur in locations that are external to the device (e.g., one or morenearby mobile devices, other computers, one or more remote computers,etc.).

It should also be noted that many or all of the determinations and/orother operations referenced and/or described herein can be useful (andtherefore provided) to other applications or processes running on thesame device (and/or external to the device) so that multipleapplications do not need to perform the same or similar determinations.Such determination(s) can be provided to such applications or processes(e.g., through an API). For example, a navigation application that wantsto prevent a driver from the distraction of inputting a destinationwhile driving but wants to permit a passenger to do so, can beconfigured to query the application's API as to whether the device is(a) in a trip and/or (b) is being operated by a driver or a passenger.

Many of the techniques described and/or referenced herein can have oneor more components that differ for specific devices, such as based uponpreviously observed behavior of that device and/or that of a userassociated with the device and/or an environment/context associated withthe device. For example, the angles at which a device is held/oriented(such as those consistent with operation by a driver or a passenger) canbe “learned,” (e.g., using machine learning techniques are known tothose of ordinary skill in the art), the speed at which a user types andthe consistency of such speed (as a driver and/or as a passenger) can belearned, the characteristics/patterns with which a device moves/shakeswhen used by a user can be learned, or practically anything that happensrepeatedly, so as to better fit a set of rules to differentiate the roleof a user explicitly (e.g., in-vehicle role, ability to perform a task)or implicitly (e.g., from the location of user) for each particular usercan be learned.

These one or more varying components can also be classified based uponthe different contexts of each user, e.g., when a user is a driver andwhen the user is a passenger using various techniques (e.g., trainedlearning and/or untrained learning, clustering) as are known to those ofordinary skill in the art.

In certain implementations a mobile device operated by a bicyclist (oranother vulnerable road user like a pedestrian, skateboarder,roller-blader, runner etc.) can transmit the real-time location of thedevice to a remote server.

Moreover, in certain implementations a mobile device determined to beused within a vehicle (e.g., a car, truck, bus, train) by a userdetermined to be driver (or passenger) can transmits the real-timelocation of the device to a remote server (e.g., as is done incrowd-sourced SatNav applications like Waze).

Moreover, in certain implementations an application can determine (and,optionally transmits to a remote sever) the mode of transportationdetermined (e.g., bicycle, car, etc.), such as with respect to the userof the device. In certain implementations, such determination(s) can bemade in a relatively passive manner, e.g., based on the device's sensors(e.g., the accelerometer and/or gyroscope readings, changes andvariability thereto and the spectral frequencies thereof). For example,bicycles are always falling and being corrected, whereas most othervehicles are generally balanced on the ground. This distinction can bemade using the device's sensors (e.g., accelerometers, gyroscope,magnetometer, etc.). By way of further example, a transportation modecan be determined based on the determined speed (e.g., based on GPS),such as with respect to the change in speed between portions of the roadhaving different gradients (as most vehicles other than bicycles haverelatively lower sensitivity to gradient and/or gradient changes). Byway of further example, a transportation mode can be determined based onchanges of angle in turns (as bicycles angle into turns whilefour-wheeled vehicles do so much less). By way of further example, atransportation mode can be determined based on the spectral frequenciesmeasured/determined by the sensors of a device, as those determined withrespect to a bicycle are relatively different than those of the sensorsof a device being used in a car. By way of further illustration, atransportation mode can be determined relatively actively, such as byprompting a user to identify (e.g., with voice, touch, haptic, etc.inputs) the mode of transportation being used, such as prior to thestart of (or during) a trip, and/or by virtue of the fact that theinformation provided in this system can be packaged differently fordifferent use cases (e.g., bicycles vs. drivers) and the transportationmode of the device user can be determined from the application used.

In certain implementations a driver or a cyclist can elect to receivealerts (such as real-time alerts) to their device based on a particularof transportation type, mode, or class. For example, cyclists can selectto receive alerts of approaching motor vehicles and motor vehicledrivers can select to receive alerts of nearing cyclists. Such alertscan be delivered to the user by the device visually (e.g., on screen),audibly (device makes a distinctive noise) and/or hapticly (devicevibrates in some way, e.g., that may be user configurable and can evenbe integrated into the transportation equipment, e.g., device causesuser handlebars to vibrate, device causes the steering wheel to vibrate,etc.).

FIG. 38 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3805 one or more inputs can bereceived, such as in relation to a user device. At 3810, the one or moreinputs can be processed, such as in order to determine a transportationtype associated with the user device. At 3815, the transportation typecan be processed, such as in relation to one or more aspects associatedwith one or more other devices. In certain implementations, thetransportation type can be processed in order to generate one or morenotifications, such as with respect to at least one of (a) the userdevice or (b) at least one of the one or more devices. In certainimplementations, the transportation type can be processed in relation toa visibility condition state. Moreover, in certain implementations thetransportation type can be processed in order to generate one or morenotifications, such as with respect to the visibility condition state.At 3820, the one or more notifications can be provided, such as to atleast one of (a) the user device or (b) at least one of the one or moredevices.

FIG. 39 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3905 one or more inputs can bereceived, such as in relation to a user device. At 3910, the one or moreinputs can be processed, such as in order to determine a transportationtype, such as a transportation type associated with the user device. At3915, the transportation type can be processed, such as in relation toone or more data items associated with the transportation type.Moreover, in certain implementations the transportation type can beprocessed in order to generate one or more notifications pertaining tothe transportation type. At 3920 the one or more notifications can beprovided, such as in relation to the user device.

Moreover, in certain implementations the referenced alerts can befiltered to be operative/employed only in certain areas and/orsituations and/or conditions, such as based upon the selection of thedevice and/or the device user's supervisors (e.g., parents, employeretc.). For example, a cyclist might choose to receive alerts of nearbymotor vehicles (a) when she is not near a city, (b) when a particularvehicle is determined to be exhibiting dangerous behavior (e.g., drivingabove a certain absolute speed, driving above a speed relative to theallowed speed on the current road (e.g., a vehicle travelling more than20 MPH above the speed limit), swerving, is determined to be a dangerousvehicle based on its current drive or from historical information,etc.), and/or (c) when the road conditions are determined to bedangerous/unsafe (e.g., poor visibility due to weather, night, windyroad etc.). In another example, a driver can choose to filter out alertsfor nearby bicycles where (a) the bicycle is on the opposite side of theroad of the driver's vehicle (e.g., as can be detected/determined by theGPS in one and/or successive readings, by the accelerometer and the roadangle (a bicycle climbing on one side of the road and a bicycledescending on the opposite side of the road have different accelerometerreadings when fixed to the bicycle with known orientation) and/or (b)the bicycle is determined to be on the sidewalk (e.g., as can bedetected from GPS and/or successive GPS readings, from the accelerometerreadings as a bicycle riding on the sidewalk approaches and leaves someintersections when the bicycle has to come down from sidewalk andre-elevate to the curbside).

Moreover, various aspects of the information learned/determinations madeby/in relation to the various techniques described herein can beincorporated into SatNav (satellite navigation) applications, such asthose that provide real-time or near real-time alerts to users (e.g.,Waze), such as with respect to road conditions or other information.

Additionally, in certain implementations information relating to thetransportation mode, such as of the vehicle within which a device ispresent/operating, can be generated/provided. For example, device userswho are determined to be riding bicycles can be provided information onthe nearest bicycle stores (e.g., for repairs), the nearest restaurants(to fuel up), the relevant recommended cyclist spots (e.g., good climbs,good off-roads), etc.

In certain implementations, information pertaining to pedestrians can beprovided, for example at crosswalks, where such users can be providedwith alerts to approaching vehicles. Moreover, in certainimplementations drivers can be alerted to pedestrians nearby to (e.g.,in or approaching) a crosswalk area.

It should be noted that while several of the techniques described hereinpertain to allowing vehicles and vulnerable road users to betterco-exist, many of these techniques can also be implemented in order toimprove the co-existence of vehicles with other vehicles or vulnerableusers with other vulnerable users. For example, it can be advantageousfor vehicle drivers to be aware of /alerted to other vehicles that areapproaching/nearing them, such as in situations of poor visibility(e.g., a blind corner or a blind turn, poor visibility conditions likesnow, fog, exiting a “hidden driveway,” etc.). By way of furtherexample, a vulnerable road user (e.g., a runner) can be alerted whenanother vulnerable user (e.g., a cyclist) is approaching, such as frombehind.

Moreover, while the techniques described herein can be employed insettings in which information is delivered with the involvement of aremote server, any or all of the described operations can also beimplemented directly between respective devices (e.g., the bicyclist'sdevice can communicate directly with the driver's device, rather thanthrough a remote server).

Additionally, such techniques can also be employed with respect to afixed device on the vehicle side (e.g., a vehicle infotainment system,an OBDII system) and/or the bicycle side (e.g., a bicycle computer).Moreover, such a fixed device can provide redundant and/or additionalsources of information (e.g., speed) or improved alerts (e.g., via alarger screen, louder speakers, more consistent remote communication,etc.) that can be used to augment (e.g., via increased accuracy and/orfunctionality), confirm (e.g., via increased accuracy) or replace (e.g.,with respect to lower latency and/or power consumption considerations)information otherwise obtained from and/or or determined with respect toa nomadic device (e.g., a portable device such as a smartphone).

It can be appreciated that various SatNav applications (e.g., Waze)provide alerts that are positionally fixed/static (e.g., that a car isstuck on the roadside in location X). Such alerts are either passed toall users or passed to users when they are near the location of thealert. As such, described herein in various implementations are alertsthat are positionally dynamic, i.e., alerts to items/occurrences whoseposition is changing (e.g., a bicycle rider, a wide vehicle, a slowvehicle, etc.). In addition, such dynamic position alerts can beprovided by the alertee.

Moreover, various navigation applications (e.g., Waze) include featureswhereby the locations of various other users can be presented(anonymously or not) to a particular user. Accordingly, usingdetection/determination techniques such as those described herein and(optionally) further incorporating the ability of a user toself-identify his/her mode of transportation, technologies describedherein can be configured, such as in conjunction with a navigationapplication, to show/indicate/provide alert(s) to the user as to themode of transportation of other users, whether in total (i.e., showingall modes of transportation for all displayed users), or selectively(e.g., showing/alerting a user only to vulnerable users, e.g., bicycles,pedestrians, etc., that are coming close, showing/alerting a user onlyto large trucks that are nearby, etc.).

Many of the techniques described herein with respect to reducing thepower consumption on the device can be apply to the bicycle/vulnerableroad techniques described herein, where, in certain implementations, oneor more sensors and/or other methods can be utilized in order todetermine whether or not a vehicle (within which a device ispresent/operating) is within a trip, and/or the mode of transportationused in such trip (e.g., bicycle, walking, rollerblades etc.).

It should also be noted that, in certain implementations, games and/orgame-related features can be incorporated into one or more of thetechnologies described herein. For example, in certain implementations,‘points’ or ‘credits’ can be awarded to a user who initiates theexecution of a determination/verification application (e.g., an ‘app’capable of determining whether a device user is likely to be a driver ora passenger). In other implementations, such ‘points’ or ‘credits’ canbe awarded to a user who successfully authenticates as a passenger,and/or such ‘points’ or ‘credits’ can be deducted from a user who failsto authenticate.

In certain implementations, it can be advantageous, such as in relationto a navigation application, to notify a user when the route that isusually optimal from their current location to their current destination(as is determined by navigation applications that implement dynamicrouting, such as Waze, as well as those using static routing), isdetermined to be sub-optimal, such as on a temporary basis (e.g., due toroad work, heavy traffic, etc.). It should be understood that thereferenced ‘current destination’ of the user can be determined, forexample, based on a user input (e.g., audio, touch, visual [e.g.,gestures], etc., inputs) into the navigation application, and/or can bedetermined (or “learned”), such as based on historical routes taken bysuch user (which can be accounted for based on the days of the weekand/or the different times of day during which such routes aredetermined to be traveled, for example).

FIG. 40 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4005 one or more navigationinstructions can be computed, such as between a first location and asecond location. At 4010, the one or more navigation instructions can beprocessed, such as in relation to at least one of (a) one or morepreviously computed navigation instructions between the first locationand the second location or (b) a previously traveled route between thefirst location and the second location. In certain implementations, theone or more navigation instructions can be processed in order todetermine one or more disparities, such as between the one or morenavigation instructions and the at least one of (a) one or morepreviously computed navigation instructions between the first locationand the second location or (b) a previously traveled route between thefirst location and the second location. At 4015, one or morenotifications can be generated, such as based on the one or moredisparities. In certain implementations, the one or more notificationscan include one or more navigation instructions that characterize anaspect of the navigation between the first location and the secondlocation in relation to the at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location. Moreover, in certain implementations,the one or more notifications can include one or more navigationinstructions that characterize an aspect of the navigation between thefirst location and the second location as an instruction to deviate fromat least one aspect of the at least one of (a) one or more previouslycomputed navigation instructions between the first location and thesecond location or (b) a previously traveled route between the firstlocation and the second location.

FIG. 48 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4805 one or more navigationinstructions can be computed, such as between a first location and asecond location. At 4810, the one or more navigation instructions can beprocessed, such as in relation to at least one of (a) one or morepreviously computed navigation instructions between the first locationand the second location or (b) a previously traveled route between thefirst location and the second location to determine one or moredisparities between the one or more navigation instructions and the atleast one of (a) one or more previously computed navigation instructionsbetween the first location and the second location or (b) a previouslytraveled route between the first location and the second location. At4815, one or more notifications can be generated, such as based on theone or more disparities.

It can be appreciated that navigation applications generally instruct auser when to take certain actions (e.g., “in 800 meters turn right”, “atthe roundabout take the 2^(nd) exit,” etc.). Accordingly, in certainimplementations such applications can be improved/augmented byconfiguring them to provide instructions to users pertaining to when notto take certain actions (e.g., “in 800 meters, at the intersection, donot take a left”, or “in 800 meters, at the intersection, go straight”).Such functionality can be advantageous to users when a route to theircurrent destination that is usually optimal is temporarily not optimal(e.g., due to road work, heavy traffic, etc.). For example, if the routethat is generally fastest from a user's home to the user's place of workincluded turning left at a particular intersection, but that route wasnot optimal on a particular day/time (e.g., due to road work, heavytraffic, etc.), and the currently best route involved proceedingstraight at such intersection, existing navigation systems might simplyomit the “turn left” instructions. However, such an omission may wellnot be recognized by a user, particularly one who frequently travelssuch a route (e.g., a commuter), and such user may likely turn left atthe referenced intersection by force of habit. Accordingly, providing anexplicit negative instruction such as “do not turn left at ” or animplicit negative instruction such as “go straight at [the referencedintersection]” and/or any other such technique that can emphasize and/oralerting the user to the recommended change can be advantageous in suchsituations. Moreover, such techniques can be particularly useful whenthe user's ordinary routes are learned/observed over time and theinstructions/notifications provided by the navigation application aregenerated and provided relative to such learned routes. In doing so,changes in routes relative to those that the user follows often caninclude negative instructions, whereas changes to routes that the userknows less well may be omitted (or less prominently emphasized), therebyfurther improving the user's driving experience. In anotherimplementation, a navigation application can provide such implicitnegative instruction(s) by advising a device user to “make a left nowinstead of at the next intersection”. One exemplary implementation isdepicted in FIG. 49.

In one implementation, which can be particularly useful to navigationapplications where the device user's travelling patterns aredetermined/learned, one or more notifications/alerts can be provided inadvance, such as to the fact that an upcoming trip is likely to takemore/less time than usual (e.g. a commute), so that the user can adjusthis/her departure time accordingly. Such notification(s) can begenerated/determined and/or provided, for example, based on an estimateof the trip travel time that is likely to prevail for a trip that isslated to start at or around the hour that the device user is likely to(or has advised that he/she will) begin his/her trip. Such estimatedtrip travel time can be determined/derived based on one or more of (a) acomparison of current traffic (e.g., determined today) at one or morepoints in time along the referenced possible routes for the referencedtrip with historical traffic data collected/determined with respect tosuch times along such routes, (b) acquiring/obtaining data (time,location) pertaining to specific events set (or likely) to occur on thatday (e.g., a sporting event, holiday, weather conditions such asrain/snow, etc.) and which may cause changes in traffic patterns alongsaid routes, and/or (c) determining/acquiring data pertaining tovehicular or infrastructure problems/incidents (e.g., crashes, roadwork, holes in the road, etc.) that may influence/affect trafficpatterns along the referenced route(s). It should be noted that the timethat the device user is likely to begin such a trip can bedetermined/derived from one or more factors such as the regular/usualtime the user begins such commute, the device's alarm clock settings,entries in the device's/user's calendar and/or user input indicating adesired departure time or destination arrival time.

In certain implementations, opportunities (e.g. for the presentation ofadvertisements, discount coupons, etc.) and/or advertisements can begenerated and/or presented at a device based on a determination of theoccurrence of one or more events (e.g., trip start, trip end, speed,trip length, etc.). In contrast to traditional location basedadvertising, such a technique can use information related to a user'strip to determine when (or what) to provide advertising and/orcommercial offers. Determinations as to which of several opportunitiesto present the user can be made based on/in relation to the determinedlocation, mode of transportation, time of day, day of week, frequency ofuser visitation to location and/or user preferences. For example, when atrip end is detected at 8:00 AM, a user can be presented with a discountcoupon for breakfast. In another example, three hours into the user'sbicycle ride, s/he can be offered coupon of a local convenience store topurchase a snack (e.g., a ‘PowerBar’).

Moreover, in certain implementations directions/instructions provided bySatNav applications to users (e.g., “turn right at the nextintersection,” etc.) that are actually confusing/ineffective/suboptimalcan be determined/discovered. For example, such directions/instructions(e.g., the audio and/or visual prompts that are provided to users whiletraveling) can be associated with corresponding user actions, such asthose that are performed concurrent with/subsequent to the providing ofsuch instructions. Upon determining that concurrent with and/orsubsequent to the proving of a particular directions/instruction (or setof directions/instructions) by a SatNav application, one or more users(e.g., relatively more users than is typical/average) can be determinedto navigate in a manner that deviates from the instructions provided bythe application (as can be determined, for example, as an instance of‘rerouting’ by the application, for example based on the user making a‘wrong turn’), it can be further determined that such adirection/instruction is relatively likely to be confusing/unclear tousers, and such a direction/instruction can be flagged for improvement.

FIG. 37 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 3705 a plurality of indications can bereceived. In certain implementations, each of the one or moreindications can correspond to at least one of: (a) a determination of astart of a trip or (b) a determination of an end of a trip. At 3710, arequest for a vacant parking location can be received. At 3715, theplurality of indications can be processed, such as in order to identifyone or more vacant parking locations. At 3720, a notificationcorresponding to at least one of the one or more vacant parkinglocations can be provided. In certain implementations, such anotification can be provided in response to the request.

A trip can be determined to have ended when a driver parks a vehicle anda trip typically starts when a driver starts a parked vehicle.Accordingly, it can be advantageous to determined and/or maintainparking information related to vehicles (e.g., where vehicles areparked, how long they have been parked, their parking habits, when theyvacate their parked position, etc.). Moreover, based on suchinformation, technologies can be implemented whereby vehicles that seekto park in an approximate particular location can be provided with toolsto assist them to do so more effectively/efficiently (e.g., faster, withless stress, cheaper, with better alignment between parkingrules/regulations and their needs, etc.).

For example, in certain implementations, information related to publicparking regulations can be obtained/referenced, such as from a database(built, for example, via crowd-sourcing). Accordingly, upondetermining/detecting a ‘trip-end’ (i.e., the end of a trip, such as inthe manner described herein) at/in relation to a mobile device, it canalso be determined that a vehicle may have parked in that location. Suchdetermination(s) can be computed with even greater accuracy, forexample, based on a determination that the device with respect to whichsuch determinations are made has also been determined to be operated bya user identified as a driver. By way of further example, when a mobiledevice determines/detects a ‘trip-start’ (i.e., the start of a trip,such as in the manner described herein) it can also be determined that avehicle that was parked in that location is likely to have vacated aparking spot.

In one implementation, users that are determined to be leaving theirparking location (e.g., as determined, for example, through the use ofone or more trip start/end determination techniques, such as thosedescribed herein, and/or through the use of a parking paymentapplication such as Pango) can be offered a reward (e.g., a parkingdiscount, cash, credit for future parking, credit or discount from a3^(rd) party, etc.) to remain in their current location for a someperiod of time, until a certain other vehicle can arrives in order toallow the parking spot to be ‘handed off’ or transferred from one userto the other. Moreover, in certain implementations, users that arelooking for parking spaces can be offered the opportunity to receive (orreserve) a parking space near their desired location in return forproviding a payment (e.g., in-app, credit card, e-wallet, etc.).

It can be appreciated that such technologies can be configured such thatthe cost (e.g., to the ‘new’ parker) and the payment (e.g., to thecurrent parker) can be static or dynamic (e.g., based on time of day,day of week, day in year, location, number of currently parked users,parking habits of users, etc.).

In one implementation the participation of a user in such a systemand/or the payments and costs thereto can be governed by the user'sreputation, as can be determined based on the user's previoustransactions.

It should also be noted that any or all instructions and/ornotifications referenced herein can be delivered audibly and/or hapticlyand/or visually.

Moreover, any/all of the referenced navigation applications and theimprovements described herein can be implemented client-side (e.g., on adevice such as a mobile device, on an in-vehicle device, on another typeof device, etc.) and/or server-side (i.e., remotely) and/or in acombination of the two.

FIG. 41 is a flow diagram of a routine that illustrates aspects of oneor more methods, such as those described in relation to one or moreembodiments described herein. In various implementations, one or moreaspects of the referenced method can be performed by one or morehardware devices/components (such as those depicted in FIG. 1), one ormore software elements/components (such as those depicted in FIG. 1),and/or a combination of both. At 4105 one or more restrictions can beemployed, such as in relation to a user device. In certainimplementations, the one or more restrictions can include a restrictionof one or more messaging services, such as in relation to the userdevice. At 4110, a message associated with a restriction overridenotification can be received. At 4115, it can be determined that themessage originated from one or more designated sources. At 4120, aninstruction can be provided, such as to perform one or more actions. At4125 the message can be provided, such as in relation to the userdevice. In certain implementations, the message can be providedconcurrent with an employment of the one or more restrictions. Incertain implementations, the referenced message can be provided inrelation to the user device, such as based on a determination that theone or more instructions have been performed.

In another embodiment, a third party can ‘page’ a vehicle driver throughthe driver's mobile device. Upon receiving such a ‘page,’ the device cansignal to the driver (e.g., using audio, visual and/or haptic means)that there is an emergency or other such occurrence that the driver mustaddress (in certain implementations by first stopping or slowing downthe vehicle). Such techniques can be useful in scenarios where a deviceoperated by a user determined to be likely to be a driver of a vehicleis put into a restricted mode so as to prevent distraction (e.g.,otherwise preventing calls, texts, etc.), because such a ‘page’ canprovide a relatively low distraction manner in which to alert the driverthat they are urgently needed.

It should be noted that such techniques can also be implemented withrespect to devices that are in other forms of “do not disturb” modes,whether they are passenger devices or not even within a vehicle.

In one implementation, such techniques can be employed whereby a partywishing to urgently contact a device user can be provided with a messagefrom the user's device indicating that the device user is currentlydriving and cannot safely communicate. The party can also be notified asto how to ‘page’ the user in urgent situations. Such a notification canbe provided, for example by/in relation to the user's device (e.g., viaa voice message and/or a text message indicating, for example that “I amdriving right now and cannot take your call, if you need my attentionurgently, please [take a certain action]”), and/or via a third party orobject (e.g., as provided by the user's company, the user's spouse, awebsite containing such information, the user's business card, etc.).

Examples of action(s) to be taken by the party wishing to ‘page’ thedevice user include but are not limited to: (i) calling a specifiedtelephone number, (ii) providing a specified code in a voicemail or IVRsystem (either on the device or remotely), (iii) texting to a specialnumber or emailing to a special address or posting to a certain URL/IPaddress, and/or (iv) texting/e-mailing/posting a special message or amessage containing a special code to the user's device. Such techniquescan signal a ‘page’ to the device directly (e.g., via a text message tothe device with a short message such as “page”), and/or indirectly, suchas by causing a ‘page’ to be communicated or signaled to the device(e.g., the party inputs the “page” code on the user's company voice mailmenu (e.g., in response to a prompt indicating that “to reach meurgently hit 4”, which, in some implementations, may be made availableonly based on a determination that the user is driving) and, inresponse, the voice mail program sends a pre-defined signal to theuser's device). It should be understood that the referenced ‘page’signal(s) can be sent/transmitted in various ways, e.g., via voice,data, RF, etc.

Upon receipt of the referenced ‘page’ signal, the driver's device can beconfigured to provide one or more alerts to the driver, such as thosethat indicated that someone is urgently seeking them. Such alerts may beprovided in any of a number of ways, such as, visually (e.g., by causingthe device to turn on and have the screen blink red), via audio (e.g.,by playing an audio file saying “someone is trying to contact youurgently” with or without the name of such person, if available) and/orhaptically (e.g., by providing a special haptic/vibration pattern toindicate a ‘page’).

In certain implementations the referenced paging feature can beconfigured to restrict those that can page a device (e.g., only contactsdetermined to be stored at/in relation to the device), so as to minimizedistraction/potential harassment.

In addition, in various implementations one or more of the variousfunctionalities and features described herein can be provided as optionswhich the user can choose to enable or disabled as desired.

Moreover, in certain implementations the device and/or one or moreapplications executing thereon can be configured to preventuninstallation of one or more applications, such as of one or moreapplications that enable one or more aspects of the variousfunctionalities described herein. For example, in one implementation, afirst application/module can monitor the ongoing execution of a secondapplication/module. Upon determining that the second application is nolonger executing, the first application can initiate thereexecution/reinstallation of the second application. Moreover, incertain implementations a device can be polled (e.g., remotely) toidentify applications that are running/installed on the device. Uponidentifying that a particular application is not installed/running, suchan application can be installed/initiated.

Moreover, in certain implementations one or more of the varioustechnologies described herein can be implemented in scenarios whereidentifying an existence of/interaction with a human user (as opposed toa computer/non-human user) can be advantageous). For example, inscenarios, such as for event ticket purchases, where vendors wish toensure that the purchaser of such items (e.g., tickets) are human users(and not computer ‘bots’ or robots programmed to perform suchtransactions), one or more of the various techniques described hereincan be implemented in conjunction with such a transaction, in order todetermine that the purchaser is likely to be a human user (by virtue ofvarious sensor-based determinations, such as those originating at amobile device, such as is described herein).

It can be appreciated that a tension exists between whether advertisershould pay for ‘leads’ (e.g., using a cost per click model) or‘acquisitions’ (e.g., using a cost per action model). Accordingly, itcan be advantageous to provide techniques/technologies that areoperative to increase the likelihood that award/promotionalpoints/credits that are converted into a discount coupon/voucheractually result in a sale. In doing so, companies that provide suchdiscount coupons can be paid/compensated more based upon the issuance ofthe coupon than is currently prevalent in existing systems/frameworks,avoiding the necessity of receiving subsequent reports from the couponhonoror in order to be paid/compensated. To do this, the time for whichsuch a coupon is valid can be limited (a “time bomb”), and user to whichthe coupon is issued can be required to be within a certain location(e.g., within a certain store) in order to make the conversion thatgenerates the coupon. For example, in order to convert United ‘frequentflyer’ miles into a coupon for a 20% discount at Marriott (for whichUnited gets paid some amount by Marriott), Marriot may wish to requirethat, in order to pay United for the mere conversion of the miles into acoupon (and not through Marriott's subsequent definitive confirmation ofsuch a booking), the customer must make the conversion of the miles intothe coupon within Marriott's hotel grounds (as can be determined viaGPS, WiFi, cell-towers, BT, camera, NFC, and/or any other suchdetermination technique, such as is described herein) and/or thevalidity of the coupon can also be time-limited (e.g., only valid forredemption within the next 15 minutes).

Moreover, in certain implementations vehicle recognition equipment(e.g., cameras) can be oriented in various locations, such as thosewhere driving is inappropriate/illegal (e.g., oriented in locations withrespect to which occurrences such as drivers driving through a gasstation in order to gain a few extra minutes during traffic, cutting inline at a highway exit, etc., can be observed). Using such camera(s),one or more vehicles who perform such inappropriate/illegal acts can beidentified (e.g., using license plate recognition technologies, as areknown to those of ordinary skill in the art). Upon identifying suchvehicles (and/or users associated with such vehicles, such as theregistered owners/drivers of such vehicles), the identity of suchvehicles (and/or users/drivers) can be processed against one or moredata items, data sets, databases, etc., such as those referenced herein,in order to determine whether such vehicles (and/or users/drivers) havehigher rate of crash or insurance claims than the population at large(or the population having one or more similar/comparablecharacteristics, e.g., the same/comparable type of car, and/or in thesame geographic area, etc.). Moreover, in certain implementations thereferenced data and/or determinations can be maintained in a databaseand insurance policies of drivers determined to be exhibiting (or notexhibiting) the same or comparable behaviors can be priced accordingly(e.g., higher or lower).

It should be noted that U.S. patent application Ser. No. 13/244,978,filed Sep. 26, 2011 (now U.S. Pat. No. 8,290,480), International PCTApplication No. PCT/US2011/052655, filed Sep. 21, 2011, andInternational PCT Application No. PCT/US2012/030017, filed Mar. 21,2012, (each assigned to the present applicant) may be relevant tovarious aspects described herein, and each of the referencedapplications/patents is hereby incorporated by reference herein in theirrespective entireties.

At this juncture, it should be noted that although much of the foregoingdescription has been directed to systems and methods for determininguser roles and/or devices usages within the context of vehicular travel,the systems and methods disclosed herein can be similarly deployedand/or implemented in scenarios, situations, and settings far beyond thereferenced scenarios. It can be readily appreciated that the user-roledetermination system 100 can be effectively employed in practically anyscenario where the determination and/or identification of a user orusage of a mobile device is of value, such as in the context ofexercising or game playing. It should be further understood that anysuch implementation and/or deployment is within the scope of the systemsand methods described herein.

It is to be understood that like numerals in the drawings represent likeelements through the several figures, and that not all components and/orsteps described and illustrated with reference to the figures arerequired for all embodiments or arrangements. It should also beunderstood that the embodiments and/or arrangements of the systems andmethods disclosed herein can be incorporated as a software algorithm,application, program, module, or code residing in hardware, firmwareand/or on a computer useable medium (including software modules andbrowser plug-ins) that can be executed in a processor of a computersystem or a computing device to configure the processor and/or otherelements to perform the functions and/or operations described below. Itshould be appreciated that according to at least one embodiment, one ormore computer programs or applications that when executed performmethods of the present invention need not reside on a single computer orprocessor, but can be distributed in a modular fashion amongst a numberof different computers or processors to implement various aspects of thesystems and methods disclosed herein.

Thus, illustrative embodiments and arrangements of the present systemsand methods provide a computer implemented method, computer system, andcomputer program product for selectively restricting a mobile device.The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments and arrangements. In this regard, each block in theflowchart or block diagrams can represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising”, when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

It should be noted that use of ordinal terms such as “first,” “second,”“third,” etc., in the claims to modify a claim element does not byitself connote any priority, precedence, or order of one claim elementover another or the temporal order in which acts of a method areperformed, but are used merely as labels to distinguish one claimelement having a certain name from another element having a same name(but for use of the ordinal term) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” or “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalents thereof as well as additional items.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges can be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of thepresent invention, which is set forth in the following claims.

What is claimed is:
 1. A method comprising: receiving one or moreindications, each of the one or more indications corresponding to aperception of one or more access points in relation to a user device;processing with a processing device, the one or more indications todetermine one or more characteristics of at least one of the one or moreaccess points; based on the one or more characteristics, determining acontext of the user device.